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

Michael Foord fuzzyman at gmail.com
Wed Feb 1 16:03:44 CET 2012


On 1 February 2012 14:54, Donald Stufft <donald.stufft at gmail.com> wrote:

>
>  On Wednesday, February 1, 2012 at 9:29 AM, Antoine Pitrou wrote:
>
> Yuval Greenfield <ubershmekel <at> gmail.com> writes:
>
>
> Obviously this isn't the only problem if the account of an SQLAlchemy
> maintainer is compromised - other threats can manifest as well.
>
>
> So, why you think PyPI has to have protections against the hacking of
> maintainers' accounts is beyond me. That's a completely unreasonable
> expectation.
>
> That's only one relatively unlikely scenario where this would be useful
> and a good change, there are other more likely scenarios where this would
> also be a good change.
>
>
> Besides, being able to delete a release is mandatory (imagine you have
> uploaded
> confidential files by mistake).
>
> Nothing in this proposal removes the ability to delete files. You just
> won't be able to re upload a file of the same name (basically version). So
> if you accidentally include confidential files in version 2.3, you can
> delete version 2.3, but you'll have to release the fixed version as 2.3.1.
>

Which can be a major hassle, even with automated release procedures
(announcements, links, etc).


>
> 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. 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.
>
> 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 those "harmless" fixes broke my software because I was depending on
> that behavior and now my software just stops working. For no reason what so
> ever. What's worse is it still works on some computers (where I have the
> _original_ version installed) but on other computers it just doesn't work.
>

There is a big difference however. Python.org is a distributor of software
and we promise not to do that. PyPI is not a single distributor with
distribution policies - it is a platform for individual package authors to
provide downloads, with their own distribution practises and policies.

The security features you want from pypi can already be had by pinning
secure hashes to distribution versions.

Feel free to carry on arguing. Fortunately when there is a controversial
issue at stake with no consensus (several strong +1 and several strong -1
in this case), the status quo wins. Absent a BDFL decision of course. ;-)

All the best,

Michael Foord




>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>


-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120201/efe68733/attachment.html>


More information about the Catalog-SIG mailing list