It took me a while to realize what I don’t like about PEP 458. It mixes the issue “How to survive a compromise of PyPI” with a technical solution (TUF). It feels like the PEP is tailored for TUF without exploring alternatives or even verifying if the PEP is asking the right questions. TUF might be the only viable solution, but it’s impossible to gauge when the text is written as “Any security framework you like as long as it is TUF”.
I also feel like the PEP is not written for consumers of PyPI. It gets very technical very fast. Although I’m working in security engineering and deal with security on a daily basis, I find the PEP hard to read. Perhaps it would help if you split the PEP into a general, less technical and more user oriented PEP and a technical PEP for TUF+PyPI. @steve.dower did a really good job with PEP 551 and PEP 578.
I would like to see a general and user-oriented PEP about PyPI security to answer these questions:
- How is a package owner/maintainer able to verify that PyPI is serving correct and unmodified files?
- As a user of PyPI how can I make sure that pip installs correct and unmodified packages?
- As a user of PyPI how can I protect myself against typo-squatting attacks or compromised versions of a package?
Personally I see malicious content and package trust as a more pressing issue than a compromise of PyPI infrastructure. As a member of the Python security team (PSRT) I’m getting reports about typo squatting or malicious packages every week. (Fun fact: There we four email threads about malicious content on PyPI this month and today is just Dec 4.) There might be easier ways to detect a compromise of PyPI until TUF is implemented, e.g. PyPI could push SHA-256 hashsums of all files to a git repo or to an append-only database similar to Certificate Transparency?
Update: Fixed typo (thanks Jack from LWN 
)