[Catalog-sig] Proposal: close the PyPI file-replacement loophole

[Antoine Pitrou]

Donald Stufft <donald.stufft <at> gmail.com> writes:
> I don't even understand why people are having this discussion. PyPI is not a
> packaging *authority*. It's not Debian or Fedora or anything like that. It's
> just a place for people to publish files and metadata. You can't trust it any
> more than you can trust the uploaders themselves.
> 
> Semantics arguments are boring and tired.

Just because you don't understand them doesn't make them irrelevant.
PyPI is *not* secure. Any maintainer can upload whatever (s)he wants. You are
asking for a fix that won't do any good for the general problem.

> People depend on PyPI and the packages installed there. They depend on the
> ability to pin to a specific tested release of libraries and they should be
> able to depend on the fact that if they ask for version 1.1 of library XYZ
> they will always get the exact same package.

Are you sure you will get the "exact same package"? What if the Linux version
has different contents from the Windows version? Or the py-2.6 version was not
built properly (while the py-2.7 version was)?
Perhaps there was originally only a source release, and the attacker added some
download links for malicious binary builds?

> What if python.org decided to replace the download links for Python 2.7.2
> with a new version of Python 2.7.2 with new bugs fixed, or maybe a typo?

What if? That may be a good reason to stop trusting python.org.
Similarly, if a maintainer of a 3rd-party package uploads a significantly
different file for a given release, you should perhaps stop trusting them too.
But *you* must make that decision. You can't ask an automated software system to
solve trust issues for you.

> What if those "harmless" fixes broke my software because I was depending on
> that behavior and now my software just stops working.

What if? The right attitude is certainly not to complain to PyPI. Instead,
complain to the maintainer.

Regards

Antoine.