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

Improving the security posture of the CPC #1300

Closed
tobie opened this issue Apr 25, 2024 · 50 comments · Fixed by #1326
Closed

Improving the security posture of the CPC #1300

tobie opened this issue Apr 25, 2024 · 50 comments · Fixed by #1326

Comments

@tobie
Copy link
Contributor

tobie commented Apr 25, 2024

In light of the various security concerns raised across open source over the last few weeks we should revisit our policy to become a CPC member and/or what level of internal access this role gives you.

Some suggestions to get the discussion started:

  • prune membership every 3 months
  • require presence and input during CPC meetings for a certain period of time before becoming a member
  • have a separate security mailing list with maintainers + CPC voting members + chairs + board + security collab space members
  • be championed by an existing CPC member

Given the extraordinary context, I'm going to exceptionally block open CPC membership requests until we've made progress on this issue. So let's prioritize moving forward with this asap.

@marco-ippolito
Copy link
Contributor

marco-ippolito commented Apr 25, 2024

I agree with pruning, but I think 3 months is too short, Id suggest 6 months.
Also I dont agree the "champion" initiatiave since people from one of the various projects hosted under the foundation might not be connected with any other CPC member.
For the other 2 points +1

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

Also I dont agree the "champion" initiatiave since people from one of the various projects hosted under the foundation might not be connected with any other member.

Maintainers could be champions.

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

I agree with pruning, but I think 3 months is too short, Id suggest 6 months.

The charter says 3. We ping people before we prune the list and its also fairly easy to get re-involved.

@ovflowd
Copy link
Member

ovflowd commented Apr 25, 2024

Also I dont agree the "champion" initiatiave since people from one of the various projects hosted under the foundation might not be connected with any other member.

Maintainers could be champions.

Your initial definition already covers this since each project requires at least one maintainer to represent it within the CPC. But I agree that we could explicitly define both existing CPC Voting Members and a Project Maintainer (a Node.js TSC voting member, for example) who can also champion someone.

I believe this fits with the goals of the CPC as, after all, we want to support our projects better, and as such, CPC members must have a certain understanding of the communities they're representing.

I would also ask if we can define an exception, for example, sometimes industry-leading representatives want to join the CPC for numerous reasons, and they have a lot to bring to the table, on such circumstances, I believe that a Foundation Staff championing + having a consensus (vote) from CPC voting members to override previous requirements... Or at least I believe we should have a mechanism that could allow us to bring industry-leaders to the CPC... (But I'm neutral with this particular point)

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

@ovflowd to be clear, the idea isn’t to change anything in terms of openness or who should be on the CPC, as that isn’t a concern. We just want to make sure that folks who join the CPC are trusted community members. So anyone who is “industry-leading” is a trusted community member by definition.

@Trott
Copy link
Contributor

Trott commented Apr 25, 2024

  • prune membership every 3 months

Here's what the charter says:

Regular members who have not been active in GitHub, participated in meetings, or other work of the CPC for 3 months may be removed from the list of Regular members.

It's that last "other work of the CPC" that can create many loopholes and uncertainty. But I think it makes sense to try to make this work, and if "other work for the CPC" proves to be problematic, we can see about updating the charter.

In Node.js, "other TSC work" used to be enough to keep people on the TSC, and it meant no one was ever removed because nobody could ever be sure that someone didn't participate in a conversation somewhere or something like that. We changed it to something that tooling could detect, which worked slightly better. But really, a culture change was needed (and is still needed there). The CPC is not the TSC, so YMMV and all that.

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

@Trott I think you're spot on saying that this is mostly about culture. I think we need somewhat of a mindset shift if we want to be able to keep the same openness while making sure we're just more resistant to potential threats. This is similar to rotating certs or adding expiration dates to tokens: it's just better hygiene. Sure, it does mean that if you're not paying attention, you'll be logged out and will have to start the process from scratch. But if it does lower the risk, it might be a worthwhile tradeoff to make.

@ljharb
Copy link
Member

ljharb commented Apr 25, 2024

@tobie Can you elaborate on exactly what couldn't be achieved (in the "attack" sense) with your proposed process, that can be with the current process?

@UlisesGascon
Copy link
Member

I agree with the goal. I'm not entirely clear on the meaning or context of 'be championed.' Is this meant to discourage self-nomination? I believe it's fine to prevent self-nomination since the group is very open, allowing non-members to engage in our initiatives and find a way to be recognized by others.

The separate list sounds like a fantastic idea! ❤️

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

@ljharb my understanding from having talked to IT security experts is that you're essentially trying to increase the cost of attacks, not prevent them. With that in mind, the idea is to implement defenses with a high cost to attackers for a minimum impact to what we value (e.g. transparency, openness, privacy, etc.).

@ljharb
Copy link
Member

ljharb commented Apr 25, 2024

Right - but I'm wondering what the attacks are here, that you're trying to reduce the cost of.

@tobie
Copy link
Contributor Author

tobie commented Apr 25, 2024

One of the concerns raised was the number of people with access to the mailing list with which we communicate during a security incident.

@ljharb
Copy link
Member

ljharb commented Apr 25, 2024

Sure. But if someone wanted to get that access for nefarious purposes, why is "a human attending a few meetings" a barrier to them getting that?

@ovflowd
Copy link
Member

ovflowd commented Apr 25, 2024

Sure. But if someone wanted to get that access for nefarious purposes, why is "a human attending a few meetings" a barrier to them getting that?

Because you put a face to the attacker? It becomes way harder for them to not be pinned down, otherwise 🤔

@ljharb
Copy link
Member

ljharb commented Apr 25, 2024

Sure, but the xz incident was likely state-sponsored. How hard would it be for a government to come up with someone technical who can donate their face? Also AI-generated video faces are getting pretty good; it would be pretty easy to fake a face too.

I'm all for being careful, but if extra process and friction isn't going to meaningfully protect against the sophisticated and well-resourced attacks we're concerned about, then it's harmful to have them.

@ctcpip
Copy link
Member

ctcpip commented Apr 25, 2024

Can someone clarify the specific problem(s)/risk(s)? The only security risk mentioned was access to a privileged mailing list. If that's the only thing, that's fine, but if it's more than that, it's important to be clear about what those risks are, because otherwise there's no way to know what is being solved for and no way to assess how effective proposed solutions will be.

The Principle of Least Privilege (PoLP) should apply as much as possible. I would hope and expect that CPC members do not get any elevated privileges automatically, aside from the write role on the CPC repository. This also goes for other groups mentioned above, such as security collab space members.

have a separate security mailing list with maintainers + CPC voting members + chairs + board + security collab space members

If that mailing list will possibly contain sensitive security information, that list of people is already way too large. See: PoLP. As situations arise, you can expand who needs to be looped in as necessary, but the default should not be so extensive.

I suggest decoupling CPC membership from security/privileges as much as possible; that should help to resolve some of the concern with regard to onboarding new folks. You don't want to be getting heartburn when onboarding someone because onboarding automatically grants some privileges that introduce security risks. (This goes for all other organization roles as well.)

Ideally, you should care very little, from a security perspective, about who is on the CPC. On the other hand, you should care a lot about who has elevated permissions, independently of their role(s) in the organization.

It is likely to be easiest/cleanest to have a separate group for elevated permissions. So maybe one solution is to have a 'security mailing list' group, whose members may be pulled from other various groups, but does not automatically include any entire group on the basis of membership alone. It may be a little more administrative overhead, but is a lot better from a security posture and avoids the anxiety and hesitation where an individual may need access to a but not b.

@anfibiacreativa
Copy link
Member

I am somewhat concerned about

require presence and input during CPC meetings for a certain period of time before becoming a member

Unfortunately my experience is that is is close to impossible to hold meetings outside of a certain timeframe. That makes them relatively difficult to attend in the event of having competing priorities or living in a certain timezone. If a member is active delivering in some other way, or participating async of issues, etc, may be a good indicator of engagement?

@ovflowd
Copy link
Member

ovflowd commented Apr 26, 2024

@anfibiacreativa these requirements would be for becoming a member, not for staying active.

I strongly believe that people interested in the CPC should join meetings, as that's where most of the collaboration and discussions happens. Yes, GitHub also has a lot of activity, but genuinely a lot of context only exists within the meetings...

I feel you regarding the timezone and life priority conflicts, I also haven't been active on many meetings, but I believe that for folks interested in joining the CPC it is highly important that we get to know them...

@ovflowd
Copy link
Member

ovflowd commented Apr 26, 2024

How hard would it be for a government to come up with someone technical who can donate their face? Also AI-generated video faces are getting pretty good; it would be pretty easy to fake a face too.

Fortunately we still live in a world where these AI-generated traits are easily noticeable if in real time 😅

Im not saying it is not possible, but at least we cam reduce the risks.

@tobie
Copy link
Contributor Author

tobie commented Apr 26, 2024

Thanks for framing the issue so astutely, @ctcpip. Indeed one of the main problem seems to be that we're currently conflating CPC membership with elevated access (to both mailing lists and private conversations).

I guess we need to clarify our needs when it comes to security (roles, comms channels, kinds of threat, what else?) and then define criteria for elevated access to those (so we won't entirely avoid the unpleasantness of this conversation, unfortunately).

Another concern is the credibility that certain credentials (such as being part of the OpenJS GitHub org) provide, and how they can be used to manufacture trust and obtain elevated access elsewhere. I'm not sure how fine-grained GitHub allows us to be on that front.

@mhdawson
Copy link
Member

mhdawson commented Apr 26, 2024

Can someone clarify the specific problem(s)/risk(s)? The only security risk mentioned was access to a privileged mailing list. If that's the only thing, that's fine, but if it's more than that, it's important to be clear about what those risks are, because otherwise there's no way to know what is being solved for and no way to assess how effective proposed solutions will be.

This resonates with me. Open Source lives with a number of risks. It seems like people don't worry about these (and seem to be unwilling to invest $ or effort) until some high profile incident occurs and then there is often a rush to sugest some "point solutions" that may or many not reduce the most important risks. At the same time some of the solutions may erode Open Source, project, or team principles so its important in my mind that we make sure the value is worth the cost. Long way of saying that I agree with @ctcpip that we need to define the problem being solved, along with what value is going to be achieved in terms of overall risk reduction.

@ctcpip
Copy link
Member

ctcpip commented Apr 26, 2024

Another concern is the credibility that certain credentials (such as being part of the OpenJS GitHub org) provide, and how they can be used to manufacture trust and obtain elevated access elsewhere.

I agree there is potential for this to give 3rd parties a false sense of trust in an individual, to some degree.

However, I suggest that you probably don't want to put on your plate the problem of trying to solve for poor 3rd party security practices. 😀

I'm not sure how fine-grained GitHub allows us to be on that front.

It doesn't, really. Anyone added to the org will have the option to display org membership. 'Outside collaborators' can be added but only directly to a specific repository - and this makes managing security policy for them a nightmare (which is itself a non-negligible security risk), because you've lost the ability to manage access at the team level.

@tobie tobie changed the title Revisiting our policy to become a CPC member Improving the security posture of the CPC Apr 30, 2024
@tobie
Copy link
Contributor Author

tobie commented Apr 30, 2024

Our May 7 CPC working session will be on this issue.

@tobie tobie pinned this issue Apr 30, 2024
@tobie
Copy link
Contributor Author

tobie commented May 7, 2024

We discussed this in today's CPC working session.

  • It was pointed out that the CPC's governance doc already included a number of requirements to become a CPC member.
  • A suggestion to requiring a new member sponsor was made. It was pointed out that the requirements in the governance document already implied this, but that this could be a barrier to entry.
  • There was a discussion about requiring some facetime (not necessarily regular meeting attendance), both to build rapport and for security reasons, notably as an additional barrier against compromised accounts.
  • A distinction between CPC membership and security access was made again, but it was also pointed out that trust requirements around CPC private decisions remained outside of security concerns.
  • It was also raised that the difficulty in making public decisions around CPC membership mirrored the concerns we had last year with the travel fund.
  • There was overall agreement that our polices seemed good enough but that our process was really causing issues right now, and that the CPC should have the discussion in private, much like it has already for travel fund, as to whether or not someone should become a CPC member.

Next steps: ask @bensternthal whether the travel fund request intake process could be repurposed for CPC membership requirements.

@ljharb
Copy link
Member

ljharb commented May 23, 2024

(they also get the ability to access the cpc-private email list, i believe)

@PaulaPaul
Copy link
Contributor

Thanks @ljharb - I think it is still a low risk to allow admissions of regular CPC members via CPC consensus. I haven't heard anything about that designation that would directly result in a code vulnerability. Do you?

@ljharb
Copy link
Member

ljharb commented May 23, 2024

No, certainly not. I think the primary consideration here is information security, not application security.

@PaulaPaul
Copy link
Contributor

Interesting - Can you help me understand the information security threat surface for CPC private sessions?

Given the CPC meetings, minutes, and processes are all open in GitHub, then we can narrow the threat surface to just the CPC private sessions. Having participated in those private CPC sessions, I have not personally been exposed to anything that is sensitive enough that I could act on it with malicious intent.

Even the few times I've heard of sensitive things like code of conduct issues, the details of those issues have always been kept very secure (for example to an incident response team that I was not
part of just by being a regular CPC member).

Do you think the information security threat surface can be narrowed to just the CPC board members and the OpenJS board members who have the ability to share sensitive information in the private CPC sessions?

If that is the case I would say the threat surface should be minimized at the source vs restricting acceptance of regular CPC members.
What do you think?

@ljharb
Copy link
Member

ljharb commented May 23, 2024

The private sessions, as well as the private email list, have had a number of things discussed that:

  • were safe to be eventually public, but it was important that they remain private for a time window
  • might be personally embarrassing to individuals were they revealed publicly
  • might indicate that a specific project is vulnerable to social engineering attacks

… and other delicate matters.

Don't get me wrong - I think we should unblock new CPC member requests immediately. I think that a viable approach in parallel would be delaying private access (sessions and email list membership) until the existing CPC feels that the new member has engendered sufficient trust.

@PaulaPaul
Copy link
Contributor

Procedurally, we could also do something as simple as requiring a comment with justification when anyone approves a PR for a new regular member.

I saw that a request came through yesterday and received one approval, with a comment noting that two approving reviews are needed. Procedurally it might help add confidence to the process if approving those PRs required some note of why it was approved (e.g. 'I work with Jon on the project and have joined several calls with him'). That could be a simple step forward and help us unblock requests while we work out longer term / ongoing improvements.

@PaulaPaul
Copy link
Contributor

The private sessions, as well as the private email list, have had a number of things discussed that:

  • were safe to be eventually public, but it was important that they remain private for a time window
  • might be personally embarrassing to individuals were they revealed publicly
  • might indicate that a specific project is vulnerable to social engineering attacks

… and other delicate matters.

Don't get me wrong - I think we should unblock new CPC member requests immediately. I think that a viable approach in parallel would be delaying private access (sessions and email list membership) until the existing CPC feels that the new member has engendered sufficient trust.

This is great - it does clearly define the information security threat surface. I think all that information comes from an upstream contact that is either the CPC board or OpenJS foundation board? If so, the risk should also be addressed at the source (for example, answering the question of 'when do sensitive matters require a private CPC session'?). Keeping sensitive information out of the private CPC session unless absolutely necessary (minimizing the threat surface) might be worth considering. But in the meantime, I agree we should unblock accepting regular members.

Perhaps disband private CPC sessions until this issue is resolved?

@ljharb
Copy link
Member

ljharb commented May 23, 2024

That doesn't seem viable either; we need to be able to discuss things privately as they arise :-/

@PaulaPaul
Copy link
Contributor

PaulaPaul commented May 24, 2024

Perhaps another way to reduce the threat surface is to continue having private seasons but restrict those to CPC board members and OpenJS board members (until this is resolved) would that work?

@tobie
Copy link
Contributor Author

tobie commented May 30, 2024

This was discussed during yesterday's CPC regular meeting call. The CPC agreed to leveraging same infrastructure and process as for the travel fund:

  • private intake through web form
  • decision in private CPC session
  • email reply to candidate
  • public announcement via PR if request approved
  • transparency report similar to travel fund

Next steps:

  • define questions based on governance / charter requirements for intake form
  • update relevant processes and policies

@bensternthal
Copy link
Contributor

In our CPC working session today we brainstormed on the form fields. Below is a draft form that captures what we discussed in that meeting. Please add comments and suggestions to this issue. Thanks!

https://forms.gle/wmywYUpgqN9uEFYt8

@ljharb
Copy link
Member

ljharb commented Jun 4, 2024

If, No - Would you attend the CPC calls if they were scheduled at a different time?

an "if" question either needs an N/A option, or to not be required :-) (also, multiple choice doesn't seem correct)

@ctcpip
Copy link
Member

ctcpip commented Jun 4, 2024

looking good, for the most part. some suggestions:


-Please note that even if you are not yet eligible, you don’t need to be a regular member to attend CPC meetings and contribute to the work of the CPC and other OpenJS activities and initiatives.
+Please note that you don’t need to be a regular member to attend CPC meetings or to contribute to the work of the CPC and other OpenJS activities and initiatives.

-If you have worked closely with specific individuals in a larger project and would like to briefly share their names or GitHub handles, feel free to add them here
+If you have worked closely with specific individuals in an OpenJS project or collaboration space and would like to share their names or GitHub handles, feel free to add them here

Have you read and confirmed that you are eligible as documented...

need a question mark at the end


replying to Jordan:

an "if" question either needs an N/A option, or to not be required :-) (also, multiple choice doesn't seem correct)

the 2nd question isn't required to answer, but yes the first question (yes/no) needs to be a dropdown

@ljharb
Copy link
Member

ljharb commented Jun 4, 2024

@ctcpip at the time of my comment, it was marked required - now it seems to be both optional and a dropdown.

@mgol
Copy link

mgol commented Jun 5, 2024

Hi! I am one of two jQuery representatives to the CPC. A few remarks from me:

  1. I don't have a problem with showing my face from time to time, but CPC meetings are hard for me to attend: they're at hours where I either have work meetings or I need to go back home to my family. Having small kids makes timing less flexible.
  2. I have realized that at the very least I should be more active in this repository; I plan to improve on that going forward.
  3. What do we want to happen if none of CPC representatives of a specific OpenJS project are active enough to fit the criteria? Do we want to leave such projects without an official representation?

@tobie
Copy link
Contributor Author

tobie commented Jun 5, 2024

Looks good to me too.

A few suggestions:

- Please list the OpenJS projects and/or collaboration spaces where your involvement can be verified.
+ Please list the OpenJS projects and/or collaboration spaces in which you are regularly involved.

Reason for change suggestion: we don't want to sound like we're policing folks and the involvement needs to be more than episodic.

- Are you able to attend the regular CPC calls, based on the currently scheduled times? 
+ Are you able to attend the CPC meeting regularly, based on the currently scheduled times? 

Reason for change suggestion: regularity is key here. Neither from time to time, nor all the time.

@ljharb
Copy link
Member

ljharb commented Jun 5, 2024

@mgol makes a very good point.

Official Foundation project representatives should have a much lower bar for being regular members; this is a very different category than community regular members. Specifically, there should always be at least one representative for each project capable of being on the CPC, even if they can't attend meetings.

Either way, though, the intention isn't to mandate meeting attendance, but to establish trust, and project maintainers/reps already have that trust.

@ovflowd
Copy link
Member

ovflowd commented Jun 5, 2024

@mgol makes a very good point.

Official Foundation project representatives should have a much lower bar for being regular members; this is a very different category than community regular members. Specifically, there should always be at least one representative for each project capable of being on the CPC, even if they can't attend meetings.

Either way, though, the intention isn't to mandate meeting attendance, but to establish trust, and project maintainers/reps already have that trust.

I thought that project representatives to the CPC are CPC members per definition.

@bensternthal
Copy link
Contributor

Form has been updated with everyone's feedback.

@ctcpip
Copy link
Member

ctcpip commented Jun 13, 2024

looking good! thanks Ben

@ljharb
Copy link
Member

ljharb commented Jun 13, 2024

LGTM as well

@bensternthal
Copy link
Contributor

Next step is to update/change the process documentation. As part of this we will address @mhdawson 's concerns/feedback around ensuring we are adhering to the lazy consensus model.

@joesepi
Copy link
Member

joesepi commented Jul 9, 2024

Meeting notes:

  • We have improved the intake process for new CPC membership
  • Decided the rest of the process was satisfactory
  • Chris recommends closing this issue while also creating a new issue(s) specific to remaining tasks, process
    • File new issue for creating a security mailing list if necessary
    • File new issue to create reminder for pruning the membership
  • Can probably merge the related pull request: Update CPC Regular Member Process #1326

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

Successfully merging a pull request may close this issue.