[Catalog-sig] Proposal: close the PyPI file-replacement loophole
donald.stufft at gmail.com
Wed Feb 1 16:31:03 CET 2012
On Wednesday, February 1, 2012 at 10:18 AM, Antoine Pitrou wrote:
> Donald Stufft <donald.stufft <at> gmail.com (http://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.
No, them being irrelevant makes them irrelevant.
> > 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 (http://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 (http://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.
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalog-SIG