Who should be in @nodejs/security? Who should have access to the private repo?

[mcollina]

As titled, here are some basic questions that we need to clarify:

1. are all @nodejs/tsc members automatic members of the security team?
2. how do we rotate out members of @nodejs/security that are no longer active? should they serve terms, similar to what the TSC might get?
3. how do we avoid discriminating against one security company with another? It seems they would all want to be part of this.

[jasnell]

Let's take a slightly different approach with this. Here are the current members of the @nodejs/security team. Let's audit the list and call for a "recertification" ...

• @sam-github Sam Roberts
• @mscdex Brian White
• @dougwilson Douglas Wilson
• @ofrobots Ali Ijaz Sheikh
• @evilpacket Adam Baldwin
• @joaocgreis João Reis
• @jbergstroem Johan Bergström
• @grnd Danny Grander
• @indutny Fedor Indutny
• @bnoordhuis Ben Noordhuis
• @trevnorris Trevor Norris
• @ChALkeR Сковорода Никита Андреевич
• @saghul Saúl Ibarra Corretgé
• @jasnell James M Snell
• @rvagg Rod Vagg
• @MylesBorins Myles Borins
• @evanlucas Evan Lucas
• @thefourtheye Sakthipriyan Vairamani
• @Trott Rich Trott
• @shigeki Shigeki Ohtsu
• @addaleax Anna Henningsen
• @Fishrock123 Jeremiah Senkpiel
• @ejratl Emily Ratliff
• @targos Michaël Zasso
• @cjihrig Colin Ihrig
• @joshgav Josh Gavant
• @mhdawson Michael Dawson

I would apply a few immediate criteria to filter this:

1. Anyone on this list who is not also currently a committer to either nodejs/node or nodejs/http-parser (which correspond to the two *-private security repos we manage) should be removed automatically.

2. Anyone on this list who has not responded to or participated in security related discussions within the past year should be removed automatically.

Then, we can then take a look at who else is left.

[dougwilson]

SGTM

[sam-github]

My two bits:

I myself pass criteria 1,2, though I haven't actually fixed any sec vuln. Hm, unless we count the zlib update to address the very, very low CVEs issued against it.

I have found it quite useful to have access to the issue history, particularly when preparing nodejs/security-wg#35, and also it generally helps understand what's going on inside the black box of security. This wouldn't have been necessary if we had a issue tracker that allowed issues to be made public after the security release was made. I mention this, because its an example of our tooling creating a situation where non-security sensitive work (like retroactive review of all the vulns) requiring a person to be a sec group member.

I think part of the "who should be a member" problem could be addressed by better tooling, like Hacker One, see #344, because it would allow a smaller group of people to be assigned the responsibility of assuring reports are addressed - where addressed might mean communicating "not a sec vuln, post to the issue tracker" and making the issue public for the historical record, or could be pulling in ANY small set of nodejs collaborators (not just ones on the security team) who have the specific relevant expertise (and time at that moment) to fix the vuln. It makes the set of people who can work on vulns more dynamic, and more targetted, and increases security because only the handful of people who do first-line triage and the one or two people actually fixing will even have to know there is a vuln being fixed. It would allow most of the list members to step back of the sec team, particularly people who are there because if (for example) a V8 upgrade is required to fix a vuln, there needs to be a couple people permanently on the list with the time and expertise to do the fix.

[Fishrock123]

I've mostly been trying to move issues along here and there, as I'm not really useful in figuring out outcomes at a technical level I don't need to be on it but it may be useful for more organizational reasons.

[joaocgreis]

I am on the team mainly for two reasons:

• Helping with Jenkins during security releases (or any issue related with build infra)
• Windows specific issues

I'd be happy to be pulled in only for those types of issues, or to remain in the team while there's no process for temporary members.

[Trott]

This and also how we determine membership on the security@ reporting address need to get some resolution. Labeling tsc-agenda. @nodejs/tsc PTAL

Refs: nodejs/CTC#149
Refs: #354
Refs: nodejs/email#67

[Trott]

pinging for input: @nodejs/security @nodejs/security-wg @bengl

[Trott]

Framing for TSC conversation:

• How we determine membership of the nodejs/security team and the security@ nodejs reporting email address is (as far as I can tell) undocumented and therefore somewhat arbitrary. Someone needs to pick up the action item of documenting the process and shepherding it through the necessary approvals, which probably just means TSC approval.

[bengl]

I think for simplicity's sake, as a first step, the security@ email alias and the @nodejs/security team ought to be the exact same set of people. Once a mechanism/process for inclusion in that group is decided upon, I don't see a real need for having two separate groups.

As a second step, the security@ alias ought to be a pass-through to HackerOne or a similar tool, as @sam-github mentioned.

In terms of inclusion in the group: @jasnell's suggestion seems like a good start.

[Trott]

I think for simplicity's sake, as a first step, the security@ email alias and the @nodejs/security team ought to be the exact same set of people. Once a mechanism/process for inclusion in that group is decided upon, I don't see a real need for having two separate groups.

I not sure I agree with that, but I can see how it would seem to make sense. The way I see it, the mailing list is for people to use to report vulnerabilities to the project. I imagine it's kind of important for efficiency that there not be 20 people to talk to about who might respond, but rather just three or five. Typically, things that come in on the mailing address are opened in the private security repo so everyone can see it anyway. (I have no idea what percentage of things don't end up in the repo because I'm not on the email.)

In terms of inclusion in the group: @jasnell's suggestion seems like a good start.

Yes, a good start. Someone will have to do the work of auditing he describes. Any volunteers?

[jasnell]

I will take a first pass. (I don't generally suggest such work items without assuming that I'd be the one doing the work ;)...)

…

On Thu, Sep 28, 2017 at 19:04 Rich Trott ***@***.***> wrote: I think for simplicity's sake, as a first step, the security@ email alias and the @nodejs/security <https://github.com/orgs/nodejs/teams/security> team ought to be the exact same set of people. Once a mechanism/process for inclusion in that group is decided upon, I don't see a real need for having two separate groups. I not sure I agree with that, but I can see how it would *seem* to make sense. The way I see it, the mailing list is for people to use to report vulnerabilities to the project. I imagine it's kind of important for efficiency that there not be 20 people to talk to about who might respond, but rather just three or five. Typically, things that come in on the mailing address are opened in the private security repo so everyone can see it anyway. (I have no idea what percentage of things *don't* end up in the repo because I'm not on the email.) In terms of inclusion in the group: @jasnell <https://github.com/jasnell>'s suggestion seems like a good start. Yes, a good start. Someone will have to do the work of auditing he describes. Any volunteers? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#358 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eUpxCKMEfRYTTWi5mhzOsuVvLt0sks5snDQEgaJpZM4Pa51H> .

[codepilot]

I am interested in helping

[lance]

As discussed in the collaborator's summit security working group last week, I think it is also important to outline a policy and process for downstream repackagers of Node.js to have some insight into these vulnerabilities so that we are not faced with zero-day exploits during the time between the moment a patched Node is released and when we(they) are able to deliver a patched, repackaged version.

During the wg discussions I think it was resolved that policies and process for access to embargoed information would be handled by the Foundation Board. I'd like to keep this topic on the radar.

[Trott]

People that would be removed as part of @jasnell's step 1:

• @dougwilson
• @evilpacket
• @grnd
• @ejratl

Auditing the second part is the hard part. Here's the list of folks that would need to be audited:

• @sam-github Sam Roberts
• @mscdex Brian White
• @ofrobots Ali Ijaz Sheikh
• @joaocgreis João Reis
• @jbergstroem Johan Bergström
• @indutny Fedor Indutny
• @bnoordhuis Ben Noordhuis
• @trevnorris Trevor Norris
• @ChALkeR Сковорода Никита Андреевич
• @saghul Saúl Ibarra Corretgé
• @jasnell James M Snell
• @rvagg Rod Vagg
• @MylesBorins Myles Borins
• @evanlucas Evan Lucas
• @thefourtheye Sakthipriyan Vairamani
• @Trott Rich Trott
• @shigeki Shigeki Ohtsu
• @addaleax Anna Henningsen
• @Fishrock123 Jeremiah Senkpiel
• @targos Michaël Zasso
• @cjihrig Colin Ihrig
• @joshgav Josh Gavant
• @mhdawson Michael Dawson