Who should be in @nodejs/security? Who should have access to the private repo? #358
Comments
|
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" ...
I would apply a few immediate criteria to filter this:
Then, we can then take a look at who else is left. |
|
SGTM |
|
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. |
|
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. |
|
I am on the team mainly for two reasons:
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. |
|
This and also how we determine membership on the security@ reporting address need to get some resolution. Labeling Refs: nodejs/CTC#149 |
|
pinging for input: @nodejs/security @nodejs/security-wg @bengl |
|
Framing for TSC conversation:
|
|
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. |
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.)
Yes, a good start. Someone will have to do the work of auditing he describes. Any volunteers? |
|
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>
.
|
|
I am interested in helping |
|
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. |
|
People that would be removed as part of @jasnell's step 1: Auditing the second part is the hard part. Here's the list of folks that would need to be audited:
|
|
I'd love to stay involved if possible. I'm a lurker and read and don't pile on with a me too if my opinion has already been communicated. I talked with @mhdawson about this at the security-wg dinner and got feedback that I should be probably speaking up to add weight depending on the conversation. I'm willing to do better to stay involved. :) |
Can someone clarify this? How does it make sense to have the Board involved in this? |
|
@rvagg As I recall the discussion (I didn't take copious notes) there are concerns about a few issues.
Since many of these issues involve legally binding arrangements with corporate entities, it probably makes sense that policies, if not procedures, be determined and/or directly guided by the Foundation Board. I am not speaking for @nodejs/security, only for what was discussed in the security-wg sessions after Node Interactive last week. But as someone who is working on just such a downstream repackaging of Node.js, the issue is important to me. |
|
@rvagg I've got notes, haven't had time to post them to the sec-wg repo, this was in it. summary, probably not obvious from context: there is a desire by some redistributors of node, such as cloud providers, to get early access to sec releases so that on the day that nodejs.org releases, they can also release a fix, rather than do their 3-day delivery process while their clients have effetively zero-days. Discussions about who would decide what organizations are have the need to know early, and how they would be vetted for reliability, seems to be a useful thing for the board to do. They might have access to how other projects do similar advanced notice. Anyhow, this will be raised as a proposal soon, when someone (like myself) gets a bit out from under their node interactive backlog. |
If I recall from when I was in the conversation it was less of having the board decide and more of asking the board for advice... specifically as to how this may have been handled in other projects as well as to find out if we need to discuss this with the legal team. |
|
As @sam-github indicates, the situation is this: There are two parts of this discussion. The first part is: who within the core team will be members of the security team and thus have early access to security reports, access to the nodejs-private repo, and access to pre-release details of security vulnerabilities. The second part is: we've had companies express an interest in having access to pre-release details of security vulnerabilities so that they can prepare in advance of a secure release. That is the part that requires Foundation support for a number of reasons, not the least of which is dealing with the need for enforceable non-disclosure agreements necessary for a proper embargo. |
|
In terms of the audit, I think we want to balance between limiting to a small group to making sure it is not to hard for people to jump in and help out. If only a small number of people can see the issues there and the list is growing it may be hard for other people to see than and jump in to help. We already have a good level of trust in TSC members so I'm suggest it be members of the TSC minus those that specifically ask to be removed. I say the TSC as I see some responsibility there for the general problem of making sure we are responsive to security issues. Beyond the TSC I think it can be limited to people who are active in helping move the issues forward on a regular basis. With the move to hacker one we should be able to pull additional people in more easily on specific issues so unless people are going to be active regularly, special expertise without helping in the day to day work would likely not be a good reason anymore. |
|
I documented current membership in nodejs/security-wg#55, and attempted to describe the privacy expectations. I'm sure the wording could use improvement, please help. As discussed at NINA, I suggest once the policy is agreed on, that team members agree to the policy by PRing something into a markdown file somewhere. The PR is for discussion, I don't think the security membership and policy should be buried in a process document deep in the security-wg git repo. I think it should be in the main node.js README, along with the privacy policy (to assure users of node.js who will have access to security reports, and what the policy is wrt. how their info will be disclosed), probably just above Release team keys: https://github.com/nodejs/node/blob/668f4cff22acd69e8505cd8c83415ee5021fe6d6/README.md#release-team |
|
The discussion here has stalled. Is there a next step or can we close this? |
|
This was handled by the security WG. https://github.com/nodejs/security-wg/blob/master/processes/security_team_membership_policy.md |
As titled, here are some basic questions that we need to clarify:
The text was updated successfully, but these errors were encountered: