Improving the security posture of the CPC #1300
Comments
|
I agree with pruning, but I think 3 months is too short, Id suggest 6 months. |
Maintainers could be champions. |
The charter says 3. We ping people before we prune the list and its also fairly easy to get re-involved. |
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) |
|
@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. |
Here's what the charter says:
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. |
|
@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. |
|
@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? |
|
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! ❤️ |
|
@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.). |
|
Right - but I'm wondering what the attacks are here, that you're trying to reduce the cost of. |
|
One of the concerns raised was the number of people with access to the mailing list with which we communicate during a security incident. |
|
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 🤔 |
|
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. |
|
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
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. |
|
I am somewhat concerned about
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? |
|
@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... |
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. |
|
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. |
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. |
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. 😀
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
changed the title
|
Our May 7 CPC working session will be on this issue. |
|
We discussed this in today's CPC working session.
Next steps: ask @bensternthal whether the travel fund request intake process could be repurposed for CPC membership requirements. |
|
Question: Would Facetime require such newcomers to speak within the meetings? Or is they joining with the microphone and video turned off considered Facetime? |
|
Unfortunately, I couldn't make yesterday's call, so I don't know what was discussed on that topic then. I think there were three goals with the suggestion to make facetime a requirement for membership (for the record, I'm exposing what was discussed during the session, not formulating a personal opinion on the matter):
In light of the above, it would image that (1) and (3) above would require regular facetime (with video turned on, that is). |
|
Now that we have a well defined consensus process for the CPC, it can be used to evaluate existing requests for regular CPC membership. I think it is important that we unblock those requests while we resolve this issue. Applicants can be considered on a case by case basis, and approved through the CPC consensus process. This is a low risk way to unblock those requests, which are important to the growth of the community and contributors. When someone becomes a regular CPC member, the only added access to information that is granted is the ability to participate in private CPC sessions. There is no additional elevated access to code or infrastructure. The requests for regular CPC membership are not coming through in such volume that requests could not be handled on a case by case basis (consensus by CPC members, now that we have a clear consensus process). This is a reasonable and low risk approach until enhancements to the process of accepting regular member have been put in place. Knowing how long some of our code of conduct and procedural issues can take, I suggest we allow regular CPC membership requests to continue to be considered on a case by case basis, and resolved through CPC consensus, until this issue can be resolved. |
|
(they also get the ability to access the cpc-private email list, i believe) |
|
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? |
|
No, certainly not. I think the primary consideration here is information security, not application security. |
|
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 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. |
|
The private sessions, as well as the private email list, have had a number of things discussed that:
… 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. |
|
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. |
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? |
|
That doesn't seem viable either; we need to be able to discuss things privately as they arise :-/ |
|
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? |
|
This was discussed during yesterday's CPC regular meeting call. The CPC agreed to leveraging same infrastructure and process as for the travel fund:
Next steps:
|
|
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! |
an "if" question either needs an N/A option, or to not be required :-) (also, multiple choice doesn't seem correct) |
|
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
need a question mark at the end replying to Jordan:
the 2nd question isn't required to answer, but yes the first question (yes/no) needs to be a dropdown |
|
@ctcpip at the time of my comment, it was marked required - now it seems to be both optional and a dropdown. |
|
Hi! I am one of two jQuery representatives to the CPC. A few remarks from me:
|
|
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. |
|
@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. |
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:
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.
The text was updated successfully, but these errors were encountered: