TL;DR: Go to “What’s next” and if you want to veto those ideas, or say “but before that we need to do foo”, please speak up within the next week.
PEP 458 (“Surviving a Compromise of PyPI”) and PEP 480 (“Surviving a Compromise of PyPI: The Maximum Security Model”) are both
Deferred pending funding.
A coauthor of those deferred PEPs 458 and 480, @JustinCappos at New York University, wants to seek funding to better secure Python’s developer-to-user package pipeline. I’m doing some grantwriting (working on the proposal text) and I want to make sure that we’re only proposing to do stuff the community wants, and that we aren’t missing prerequisite tasks.
If you want to veto these ideas, or say “but before that we need to do foo”, please speak up within the next week. (We’re working on a proposal that’s due in a few weeks.)
- Finish overhauling the pip dependency resolver. (Justin was one of @pradyunsg’s GSoC mentors on this project a few years ago.)
- Secure developer-to-user package pipeline with cryptographically signed metadata: end-to-end signing. Once the Facebook-funded work on cryptographic package signing is in place, this proposal would involve adding support for generating and verifying these signatures through all the parts of the Python packaging and distribution toolchain – possibly using TUF and in-toto, possibly using some other framework.
This would be a multi-year project, with probably enough money to pay the equivalent of 1 full-time developer for a few years. If the proposal’s accepted we’ll find out around April 2020.
@dstufft and other experts: would this be okay? If so, leave a heart on this post; if not, please leave a comment saying why, preferably by 29 August.