[Catalog-sig] Proposal: close the PyPI file-replacement loophole
mal at egenix.com
Mon Jan 30 10:23:23 CET 2012
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?
I don't think that's a good idea, since it would require the
package author to issue a new release whenever something goes wrong
with an upload (e.g. missing files, corrupted archive, etc.).
Please leave the existing logic in place.
Professional Python Services directly from the Source (#1, Jan 30 2012)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Catalog-SIG