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

[Donald Stufft]

On Monday, January 30, 2012 at 4:31 PM, "Martin v. Löwis" wrote:

> > The mirror protocol, as far as I remember, does not deal with 'updates
> > of existing files'
> >  
>  
>  
> It most certainly does, and pep381client deals with it correctly.
One of the mirrors doesn't deal with it correctly. I think the one on GAE? Has caused a lot of problems for me.  
>  
> > 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.
> >  
>  
>  
> No, it won't. The mirrors will notice that the package changed, and
> recheck all files. The current implementation uses the ETag header
> to determine whether a file changed, although looking for a changed
> md5sum might be a better approach.
>  
> > so +1 for creating a new release whatever state the previous published
> > one is in - release numbers are not expensive
> >  
>  
>  
> As a guideline to package authors, I can certainly agree with that. I
> don't mind putting a note in the PyPI UI telling authors that file
> deletion is consider a violation of the social contract.
>  
> The issue at hand is whether to disallow recreation of deleted files
> entirely. I see this as a maintenance nightmare: people first delete
> the files (which we can't stop them from doing), then try to recreate
> the file, and find out that this is rejected.
>  
>  

Offhand I believe deleting the file requires using the web interface? If so it should be trivial to present a warning that states. "Are You Sure You Want To Do This? Note: You Will Not Be Able to Upload This Same FIle Again, You will Need to make a new release".  
>  
> Next, they try to delete the release entirely. Not sure whether Richard
> intended to have the file deletion markage survive that also. If so,
> they might try to delete the entire package, and re-register that.
>  
>  

It should survive the lifetime of the package. I'd also argue that it should survive past it as this is a different but similar problem. (Someone pulls a _why/mark pilgrim and deletes all their releases, someone else takes this chance to grab the package name, and uploads malicious code.  
>  
> > 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
> >  
>  
>  
> You mean, if a file is recreated, it is somehow flagged? Sounds fine
> to me.
>  
> Regards,
> Martin
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
> http://mail.python.org/mailman/listinfo/catalog-sig
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120130/06c72d2c/attachment.html>