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

[Toshio Kuratomi]

On Tue, Jan 31, 2012 at 08:45:18PM -0500, Alex Clark wrote:
> On 1/29/12 6:47 PM, Richard Jones wrote:
> >Hi catalog-sig,
> >
> >When we initially implemented file upload to PyPI it was our intention
> >that the file be immutable once uploaded. The goal was to make things
> >significantly simpler for end users - there would only ever be one
> >file with a given name. If the content changed then so must the name
> >(typically by creating a new release version.)
> >
> >After the upload facility was put in place we also added the ability
> >to delete files uploaded to pypi. This created a loophole: if a
> >package owner knew how to they could delete the file and re-upload,
> >thus circumventing the replacement protection.
> >
> >I'm considering closing this loophole by retaining a record of the
> >uploaded file (though not the contents) so that future uploads with
> >the same name wouldn't be allowed. I understand that this is how the
> >ruby gem archive handles deletion of files.
> >
> >Your thoughts?
> 
> A belated +1. Given that it's a known "best practice" to bump
> versions whenever you fix a brown bag release, I don't see any valid
> reason not to enforce this.
> 
One problem I've encountered that "requires" re-uploading is forgetting to
sign my sdists when doing python setup.py sdist upload.  There's probably
a way to use the webui to add the signature after the fact but I haven't
found a way to sign the existing sdist and upload that signature from the
command line.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120131/680aca56/attachment.pgp>