Moving packaging security coordination out of the PSRT

Packaging Coordination
,
1

This discussion recently came up on the Packaging Discord. I think we need a new coordination path for security disclosures affecting Python packaging tools. Currently, the Python Security Response Team (PSRT) is responsible for handling vulnerability reports for pip, as well as CPython.

The current process, however, is problematic:

  • Recently, most pip-related reports reaching the PSRT have in practice consisted of forwarding the report to the pip maintainers, this makes the PSRT an inconvenient relay for reports.
  • security@python.org receives a large volume of CPython reports, which makes it a noisy place for coordinating packaging-specific issues.
  • With PEP 811 making the Steering Council’s oversight of the team explicit, it feels odd for packaging security reports to go through them when packaging is overseen by the Packaging Council.
  • pip has a special historical relationship with CPython because it is bundled with the official CPython installers, however, other packaging tools share similar vulnerability surfaces with pip.
  • It is difficultly to add more packaging maintainers to the PSRT. Many of the people who should be involved in pip, uv, Poetry, conda, etc. disclosures do not need access to CPython vulnerability reports. Broadening PSRT access for packaging coordination would increase the number of people with access to the confidential CPython reports, create additional access-control/trust-boundary concerns, and still leave the coordination model somewhat indirect.

I propose creating a separate private coordination team for packaging security issues.
This would let the relevant packaging maintainers be included directly, without giving them access
to unrelated CPython reports. It would also provide a lower-volume/more organised place to coordinate issues that affect multiple tools, agree on disclosure timelines, avoid different projects learning about the same vulnerability separately etc.

I’m not very involved in the packaging world myself, so I don’t have any specific ideas as to how this could be created and maintained. That said, I am happy to help where I can setting this up, including by sponsoring/co-authoring a PEP if one is needed.

6 Likes
2

A little bit of background, I am a pip maintainer and I have very recently joined the PSRT to address exactly the issue of:

I will do my best to pick these up first, and you can @ me directly in the PSRT discord if I’ve missed anything or there are any aged issues I am unaware of.

However, as I’m doing this purely on a volunteer basis I am currently relying on the Python security team for both coverage (making sure I don’t miss anything) and experience and knowledge of security issues. And I think any transition away from reporting to the Python security team should be taken cautiously and with buy in.

That said, I would like to see a Packaging security group, in some form set up. A lot of security issues would benefit from coordination between Python Packaging installers and/or Python Packaging indexes. Whether that’s officially set up via the Packaging Council, or we start something informal now and transition to a more official model later, I don’t mind. But either way, it will require someone to agree to run and manage that space.

7 Likes
3

Thanks Damian. I really appreciate you joining us and taking this on!

I agree that we should not suddenly move the public reporting path away from security@python.org before there is a clear workflow in place. Longer term, though, I do think pip and packaging reports should move out of the PSRT’s scope. Having one pip maintainer on the team definitely helps with pip, but it does not solve the broader coordination problem for packaging, and putting all the weight on one person’s shoulders is fragile.

I and Seth would be happy to help bootstrap a new team, and to help mentor several people at once on the security coordination side if that is useful.

1 Like
4

I would be happy to volunteer my own time and effort in this if a new team for packaging specific reports becomes a reality.

3 Likes
5

This seems like a good idea to me, other packaging tools have more in common with pip compared to CPython. Agreed we don’t want the PSRT to become an “embargo list” for every packaging project.

I am willing to help bootstrap and participate in a “Python Packaging Security Team”, whether that’s co-authoring a PEP, repository, or helping setup processes. It would be good to get buy-in from other packaging projects’ existing security teams and maintainers

4 Likes
6

I’m okay with the PSRT handling reports for highly adjacent projects (e.g. I’m happy for Django to have their own team), but that might also indicate that enough of those reports end up being relevant for me that it’s just convenient and I ought to be on the new team as well?

I assume the PSF remains the CNA? That’s a valuable service for the ecosystem that I’d be disappointed if it wasn’t available, but it also requires a level of “do we know this person requesting IDs is associated with the project”, and so the more that gets scattered across teams the harder it becomes.

1 Like
7

It’s unclear to me how exactly folks here are thinking a dedicated “packaging” security team would operate, and what its scope would be.

Could someone add a few words on how they’re thinking this would work?

8

Thinking about this a bit more… I’m opposed to the proposal here. A few inline responses below outlining my understanding/thinking on it.

This was a major motivation for me personally for working with Seth during the initial setup of the PSF CNA – among other things, this prevents surprise pip CVEs being published without pip’s maintainers’ knowledge.

We’ve got three on there, all of whom are volunteers with varying availability. :sweat_smile:

I disagree, mostly because it has not been an inconsistent relay in my experience – to the extent it has been a relay. Granted, that’s mostly because @sethmlarson has been doing some great work[1]. :slight_smile:

I don’t feel that list is noisy.[2] My interest does span across both CPython and pip though.

It very much doesn’t, to me. The Steering Council has substantial powers over the Packaging Council.

The Packaging Council gains its authority over packaging matters via delegation from the Python Steering Council.

If the Packaging Council cannot (e.g., by lack of quorum) or wishes not to come to a decision on its own, it can also refer the matter to the Steering Council, whose decision on the matter will be binding.

In exceptional circumstances, a vote of no confidence may be called to remove a sitting Packaging Council member, or the entire Council. The Python Steering Council may call such votes of no confidence, with no second being necessary.

Changes proposed to this governance model must be approved by the Python Steering Council.

The only tool I can think of which fits that is uv.

Approaching this differently… The tools with the “most leverage” / coordination-needed for the ecosystem-scope issues are PyPI[3], pip and, more recently, uv[4]. Among these, pip is certainly the least well-resourced, and all of pip’s security contacts are volunteers who are on-list (with @notatallshaw being the most recent security-interested pip maintainer who wasn’t, and has since been added).

Adding pip to the PSRT was originally motivated by wanting to share the infrastructure with CPython to reduce the “overhead” associated with a better security posture for the project. I don’t think that’s changed. I guess there’s maybe some value in splitting out a PyPI + pip + uv contact, but not much more over what PSRT adding in PyPI + uv into a relevant-to-pip report would provide today.

:100: Agreed!

Most backend/workflow tools also don’t typically need the same sort of coordination work (we have a really large set of them in the post-PEP-517 world) like pip/uv/PyPI have needed, especially for the style of recent vulnerabilities that I expect motivated this discussion. They don’t even need access to any other packages’ security reports.

My understanding of the current state of PSRT membership is that the number of folks who aren’t CPython core team/PSF staff today is two[5] (one of them being a pip maintainer, one being a uv/PyPI team member) and I don’t think anyone is proposing increasing that number in the near/medium term. I also don’t see any “structural” reason we’d make substantial changes on that front.

As it stands, I don’t think it even makes sense for most packaging projects to be involved in any sort of “group them together” security contact point.

Covering build-backends and workflow tools together – Hatch, Poetry, setuptools, maturin, etc – is a significant scope expansion for what we’re even trying to do today in the community. If we try to group them with pip/uv/PyPI, it has the same “are we giving too many people access to reports” problem, regardless of whether we create a separate group from the PSRT.

I think it’s also worth mentioning here that @sethmlarson recently sent comms to PyPA-committers to nudge the projects to enable GHSA for security issue reporting.

  1. Especially since my available-for-OSS time has been limited, causing me to have been limited time to help with reports on PSRT. ↩︎

  2. Beyond the LLM-generated reports and “do you have a bug bounty?” emails, which is unrelated to this discussion. :sweat_smile: ↩︎

  3. which has a dedicated security contact channel, with relevant contacts being the PyPI admins ↩︎

  4. which has a dedicated security contact channel, with relevant contacts being the Astral team in OpenAI ↩︎

  5. Apologies if I missed someone! ↩︎

2 Likes
9

Hi @pradyunsg !

I think the overall idea here got a little fuzzy in the Discord discussion. Originally, I proposed that there should be a second team specifically for pip, but that then developed into the idea of a general packaging team. So maybe there should actually be three teams. The following is primarily about splitting pip out from the PSRT.

As I understand it, Seth is happy to be on the new team, and I don’t think this would change anything with regard to the PSF CNA.

Just some statistics for people who can’t view them, over the past 30 days there have been 49 threads with 56 people in total. I’m also partly at fault for the noisiness as I see I’m second after Seth :laughing:

IIRC, based on comments in Discord, this was reverted shortly after? This also complicates things IMO. If GHSAs are enabled, will the PSRT have access to them, and how? The current PSRT GHSA bot would need some modification. And if they are enabled, then all pip maintainers will have access, so I think it would be helpful to clarify what role the PSRT (bar Seth for publishing advisories) would play in that case.

10

:waving_hand:

Only for pip. The other PyPA projects can and should have GHSA enabled (it’s a per-project decision, with most projects being nudged to do so) – pip is one of ~60 projects under the PyPA umbrella.

And, for posterity, here’s a link to the PyPA discord discussion: Discord

A quick and dirty summary: the newest maintainer on pip wasn’t familiar with pip’s relationship with PSRT and had enabled GHSA in response to the email I linked earlier. It was disabled after a short discussion, where the idea of splitting out pip to a separate list was brought up.

I agree, and that was disabled with “we need to figure it out” with similar reasoning.

I’m not sure which discussion or Discord this is referring to.

I see. I do want to note that is meaningfully distinct from what was posted here (hence, what I was responding to above):

I propose creating a separate private coordination team for packaging security issues.

I don’t really have a strong opinon on splitting out just the pip reports. If other active folks on PSRT feel like pip reports are noise for them, I’d be OK with us splitting out just the pip reports to a separate mailing list / contact point assuming we can reuse the same infrastructure for all the other communication channels (security announce, CVE CNA etc).

Honestly, at this scope, I’d rather we discuss this on pip’s issue tracker rather than here. This also does not need a PEP - just an “this is fine” from pip maintainers is enough (with my personal preference being to also get a vibe check from PSRT on whether the wider group cares about it).

I don’t like being pedantic like this, but I feel strongly that that number of messages/participants (quantitative) is not the same as “noise” (qualitative) – “how many” != “how useful”.

3 Likes
11

Oh, I thought I had linked it in the main post, sorry: link

In that case, I’ll open a pip issue. I’ve also opened a poll in the PSRT Discord for the vibe-check.

1 Like