ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS 2 Security Working Group January Meeting

Hey everyone. The January 2020 ROS 2 Security Working Group meeting will be on Tuesday, January 28th, at 18:30 UTC, via Hangouts Meet (or by phone: +1 385-325-0281‬ PIN: ‪422 295‬#).

Agenda: https://docs.google.com/document/d/1xpBfCdDVyxfEQ8gzBsezLRd2JNOepb9si-8OFCGPmCo/edit?usp=sharing

If you have anything you’d like to add to the agenda, either write to it or make a comment here.

See you all then!

@kyrofa

really appreciate for taking care of WG, but it is really hard to participate in the meeting from Asia Local Time.

Switch to one DDS participant per context

especially on this, i want to hear about opinions from people with security perspective.

thanks,

2 Likes

Well I must say I’m very unhappy with the management so far of the security working group. I will share my cents on a few things that must be improved:

  • Scheduling of meetings following requests: This is not the first time we ask for more friendly-time meetings. Today’s one is 7.30 PM CET time. There was some “planning” reaction reflected at https://github.com/ros-security/community#meetings but still no action that I’ve felt.
  • Mechanisms to manage the group seem unactive: Following the governance PR of the WG, I filed a ticket for more direct participation yet this hasn’t been reviewed so far. This is surprising to me given “how fast” things seemed to be changing in the management of this group. Sometimes even without joint consensus!
  • Unilateral decisions, without consensus: Since Canonical has taken over the coordination of this group I’ve seen several decisions that were understood as work of the WG but didn’t receive consensus AFAIK. One recent one is this commit which unilaterally sets up vetos for Canonical themselves.

I must say I’m personally a bit concerned about other matters such as the definition of a Vulnerability Disclosure Policy being discussed here. In my opinion this is being approached unilaterly and purely from a vendor’s perspective (note that it’s security researchers the ones reporting!) and is leaving aside likely the most important aspect aside: re-assurring that ROS community cares about security and is responsibly taking actions (adopting deadlines, facilitating researchers safe disclosure paths, etc.) in this direction.

5 Likes

Thank you both for chiming in!

Yeah timezones are hard! Our meetings alternate to account for the varied timezones. For example, our December meeting was at 23:00 UTC. The February meeting is at 22:00 UTC. Is that a time you can make, or shall we add another to the rotation?

You’re right. @tomoyafujita asked back in October to see if we could include an asia-friendly timezone, which is when we started alternating times. Are you referring to another request?

Mechanisms to manage the group seem unactive : Following the governance PR of the WG, I filed a ticket for more direct participation yet this hasn’t been reviewed so far. This is surprising to me given “how fast” things seemed to be changing in the management of this group. Sometimes even without joint consensus !

The idea with membership of the github org is that it revolves around projects within the org. Despite merging the community doc, we don’t have any yet, so we’ve been waiting to review applications until we do. I should have mentioned this on the application, that was my mistake, and it’s been rectified now.

Unilateral decisions, without consensus : Since Canonical has taken over the coordination of this group I’ve seen several decisions that were understood as work of the WG but didn’t receive consensus AFAIK. One recent one is this commit which unilaterally sets up vetos for Canonical themselves.

In accordance with the TSC charter:

Each WG must be chaired by a TSC member. The chair of a WG is responsible
for all aspects of that WG’s operation, including membership, meeting schedule,
and decision-making.

We’re simply outlining the role of the chair in the community doc. Teams need leaders, and leaders need the ability to effect change. If you disagree with it, let’s chat at the meeting, or in Matrix if the time doesn’t work.

I must say I’m personally a bit concerned about other matters such as the definition of a Vulnerability Disclosure Policy being discussed here .

That google doc is the perfect place to discuss your concerns, like we’re doing.

1 Like

@tomoyafujita we’ve moved the meetings to twice a month (check out the updated calendar). Please do let me know if that later slot works for you; we can push it back further if necessary. We ran out of time today to discuss the 1-1 mapping again, so we’ll put it on the next agenda in a few weeks, which should be a better fit for your tz :smiley: .

3 Likes

@kyrofa

Yeah timezones are hard!

yes, totally understood. no pressure.

For example, our December meeting was at 23:00 UTC. The February meeting is at 22:00 UTC. Is that a time you can make, or shall we add another to the rotation?

that i could manage usually, so we already taking rounds!
i just jumped on this time too early, sorry about that.

Please do let me know if that later slot works for you; we can push it back further if necessary.

thanks, 2/11 works for Japan.

Thanks for the follow up @kyrofa. I’m leaving here a note for compleness as well.

We had a discussion at the last WG meeting and still found ourselves in disagreement. I further asked for reasoning on these changes and made a proposal myself in an attempt to be constructive.

That last part of the charter seems to be enforced in here in quite a drastic manner @kyrofa, don’t you think? After all, as things are, we introducing lock-in in this WG.

Also, we want more participation and contributions on the WG and decision-making which IMHO, should somewhat be based on the participants, of course while steered by the lead (Canonical as of now).

@kyrofa @vmayoral (cc: @gerkey)

The TSC charter is a bit under-specified on how working groups operate and the exact responsibilities of chairs, probably by design. I don’t like the idea of getting overly-formal and ending up like the ISO, but I’m going to ask that we discuss clause 5 of the TSC charter in the next TSC meeting so we can clarify what it means to be “responsible” for membership and decision-making. I don’t think the charter drafters intended to give someone a veto or to make groups have a moderated membership, but it’s best we let the TSC discuss and decide.

Who knows, perhaps the working groups described in clause 5 are a completely separate concept from the working groups we currently have, meant to be of a small number of TSC members for a short-term purpose?

To be clear, it’s not our intent to have a gate to participation in the working group. Meetings and discussions are open to everyone. However the purpose of the github org is to maintain subprojects as a working group, and in that case, levels of access aren’t (and shouldn’t be) handed out to anyone who requests it. That’s the process that we’re currently trying to develop.

We talked for 30 seconds at the end of a long meeting, with the conclusion being to continue in Matrix. Which we’re doing. And here. And now in github. All these threads are making for a really disjoint conversation. I’m always happy to talk, but I think it would be less confusing for everyone involved if we just focused on one of them. Even better, I suggest we move the conversation to this clarifying PR.

That makes more sense to me.

1 Like