nodejs-private/security membership review?

[Trott]

This WG has a policy around membership in @nodejs-private/security but the membership of that group does not correspond to policy if I'm not mistaken. Is this something that should be escalated to the TSC to deal with? Or is that policy merely a recommendation and not binding? Or does the policy need updating to reflect practice? Or something else?

[Trott]

Relevant policy: https://github.com/nodejs/security-wg/blob/master/processes/security_team_membership_policy.md

There's a @nodejs/security and a @nodejs-private/security. Are they supposed to have the same membership and all that?

[jasnell]

I think this needs escalation to the TSC. @nodejs-private/security is part of the Node.js security triage and release process. There was never an intent to allow everyone in the @nodejs/security-wg to have access to that.

[Trott]

There was never an intent to allow everyone in the @nodejs/security-wg to have access to that.

@jasnell That is not what anyone is proposing. Please read the policy. It is short and clear.

[mhdawson]

We either need to update the policy or should update the groups to match it.

I suspect that nodejs/security is a holdover before we moved over @node-private/security. Maybe we can just delete nodejs/security.

Looks like we need to update the readme as well.

The to get back into policy I think we just need to remove people who should no longer bet in security-external. I might argue we'd want to keep Joao and John as build WG members who can help out with releases but since we did not include the current policy we could start by resetting the list to 0 members.

Now that we have hacker one and can invite people to specific issues, it will be much less likely we have to "invite" people in the future.

I don't know what should be escalated unless there is disagreement with the policy.

[Trott]

I believe we keep @nodejs/security around as a mirror of @nodejs-private/security so that people who don't have access to @nodejs-security can ping the team.

[mhdawson]

@Trott then do you agree the only thing we should do is empty security-external ?

[Trott]

@mhdawson I'd leave that up to Security-WG to determine (and then request that the TSC do it, whatever they determine), but my guess is: Probably yes.

[mhdawson]

@nodejs/security-wg please comment. Proposal is to remove everybody from security-external who were meant to be people with temporary access. Now that hacker-one is in use it will be less necessary to add people to security-external.

[lirantal]

If people were added on case by case basis for the purpose of triage then this can be indeed managed through H1. However, maybe not all reports will flow to H1 and also I wonder if nodejs-private is required for accessing a closed source to iterate on for scrutiny before releases are made so basically membership there is not just for triage.

I don't really have enough context on this so excuse me I'm off on the topic.

[cjihrig]

+1 to removing security-external and giving access as needed in H1.

[drifkin]

I like using H1 for giving people temporary access.

We discussed some of these issues during NINA 2017, though there aren't too many notes: #53. At the collaborator's summit, we discussed having new temporary repos for particular security releases. I don't know if that's too much process, but it would be the right thing to do from a security perspective: if someone can't see the H1 report, they definitely shouldn't see the code!

[vdeturckheim]

LGTM. This is a pretty standard use case of H1.

[mhdawson]

I think the one thing I'd like to do at the same time is to add that members of the build wg can also have access. When there are vulnerabilities in the infra we use, they have been announced and managed in the private/security repo as well. Does that sound reasonable?

[Trott]

Michael, it's probably worth discussing, but if you want that policy change, I'd ask that you open a separate issue. I have concerns (but am not necessarily opposed) in that the Build WG has some folks on it that have been inactive for a long time and that should not IMO have access to the private repos. But I defer to the Security WG on it.

I'll take this to TSC email and then hopefully make the change and then we can close this issue.

[Trott]

Email sent to @nodejs/tsc, asking for objections to be raised in the next 72 hours.

[mhdawson]

@Trott I don't think we want all of the build WG to be on the list, only that there is a path for them to be added. I just don't want to kick people out of the security repo from the build WG who are there and have used it actively to report/track updates to infra (@jbergstroem for example)

[Trott]

@Trott I don't think we want all of the build WG to be on the list, only that there is a path for them to be added. I just don't want to kick people out of the security repo from the build WG who are there and have used it actively to report/track updates to infra (@jbergstroem for example)

@mhdawson Since you're on Security WG, will you propose the necessary modifications to the policy to accommodate this?

[mhdawson]

Yes, adding to my list of todos.

[sam-github]

@mhdawson I think this was addressed, can it be closed?