Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collaborators Inactivity Policy Review #1282

Open
marco-ippolito opened this issue Apr 17, 2024 · 3 comments
Open

Collaborators Inactivity Policy Review #1282

marco-ippolito opened this issue Apr 17, 2024 · 3 comments

Comments

@marco-ippolito
Copy link
Member

marco-ippolito commented Apr 17, 2024

Refs: nodejs/node#52459
I believe it would be great to add this discussion to the agenda.
We can have a look at the current policy for inactivity and elaborate an opinion.

cc @anonrig

@UlisesGascon
Copy link
Member

Yep, this is great! We can also extend the threat model a bit to explain how the roles in the organization can impact the final users in case of bad actors or human errors. It would be beneficial to document in simple terms all the measures we have in place to prevent this (as referenced here) and how the organization promotes individuals to those roles, etc.

I believe that from an external point of view, this might be an interesting topic to cover, especially when adopting Node.js, particularly in commercial companies.

@RafaelGSS
Copy link
Member

RafaelGSS commented Apr 18, 2024

I would like to expand this discussion to a more sensitive role of Node.js organization: Releasers.

  • Is there a security concern about keeping inactive releaser keys in our machines?
  • Is the process of signing releases from a collaborator easily exploited?
  • Should we be more restrictive to the inactive limit for releasers? And what about security-triagge group?

cc/ @nodejs/releasers

@mhdawson
Copy link
Member

mhdawson commented Apr 18, 2024

In terms of the suggested expantions, the intention was to look at it from a top level model (separate from our existing threat model) which would include all ways that supply chain security might be compromised and what we have in place already to address those concernts.. I think this would include all of the different roles we have in terms of access as well as people with no access at all. The top level view should help us understand the relative risks and were it might be best to focus our energy. One way to start might be to build the list of

  • classes instractructure that are used in the project (test machines, jenkins machnines, release machines etc.)
  • what having access to those classes of infrastructure would let people do
  • Different roles that give people different levels of access to those components
  • The projections/approaches we already have in place to mitigate risks

EDIT: which in part I meant to say all those suggestions are good ideas to include in the scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants