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

[Tarek Ziadé]

On Mon, Jan 30, 2012 at 1:46 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> Donald Stufft wrote:
> >
> >
> > On Monday, January 30, 2012 at 4:23 AM, M.-A. Lemburg wrote:
> >
> >> 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.
> > And version numbers are a scarce resource?
>
> No, but having to kick off the whole release process again
> just because something went wrong when uploading release files
> to PyPI causes plenty of trouble.
>

It's the opposite that gets you into trouble: once you have uploaded
something at PyPI, it potentially gets copied to mirrors.

The mirror protocol, as far as I remember, does not deal with 'updates of
existing files'

IOW if the release is broken and you fix it in pypi, it might stay broken
in mirrorsand the inconsistent state is much more trouble.

so +1 for creating a new release whatever state the previous published one
is in - release numbers are not expensive

what about adding a metadata flag to releases  ? e.g. "deprecated" - that
way client tools know they need to avoid this one
and developers can change the flag





> > (Even though I believe it would be acceptable to cover that particular
> use case by giving a grace period of when you can re upload).
>
> Can't we just leave dealing with that problem to the package authors ?
> It's their responsibility, not PyPI's.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> 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
>               http://www.egenix.com/company/contact/
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>



-- 
Tarek Ziadé | http://ziade.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120130/b99056a2/attachment.html>