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

[Donald Stufft]

Forwarding as I mistakingly sent this directly to Matin, sorry!  


Forwarded message:

> From: Donald Stufft <donald.stufft at gmail.com>
> To: "Martin v. Löwis" <martin at v.loewis.de>
> Date: Monday, January 30, 2012 3:36:09 AM
> Subject: Re: [Catalog-sig] Proposal: close the PyPI file-replacement loophole
>  
> A Major goal in any deployment/installation system is reproducible builds. Allowing re uploads directly goes against this goal. I (and a lot of Python developers I would imagine) purposely pin to specific versions because we *know* those versions work. Currently if I rely on PyPI or any of it's mirrors I just have to cross my fingers and hope that the file i'm getting is the file that I tested against.  
>  
> A responsible author wouldn't change his files after people are using it. Unfortunately not all authors are responsible which is why restrictions should be put in place.  
>  
> I think there are very clear bad things that could happen due to mutable packages, I can't think of a single bad thing that could happen due to immutable packages other than "if the author messed something up he might have to increase his version number". Increasing a version number is a very minor problem compared to breaking software.
>  
> So my questions to you are:
>  
> 1. What is the worst case if packages are made immutable?
> 2. What is the worst case if they are kept mutable?  
> 3. Best case for immutable?
> 4. Best case for mutable?
>  
> That I can think of it's: 1) Author Might have to "waste" a version number uploading a fix 2) Author might break (or introduce major security vulnerabilities), inadvertently or otherwise exiting software 3) People depending on packages can use PyPI and be secure in the fact that what they got today will be the same as what they get tomorrow  4) People depending on packages can get "secret" bug fixes.
>  
> Between the two the worst case for immutable is basically a noop, and the worst case for mutable is a very serious problem which leads many people to needlessly abandon PyPI for when installing packages matter and use their own internal systems. I very strongly feel that the worst case for mutable is a serious problem and it outweighs the very minor benefit package authors get from being able to re upload.
>  
> On an additional note, a good compromise might be to allow reuploads for the first 30 minutes or an hour, and after that prevent it. You still provide that minor benefit in the only situation it's a valid use in my opinion (the "oh no I just uploaded a package and it was broken"), but you let people be secure in the fact that when I test my software against a specific version, I can install that version over and over again and get the same results.
>  
> On Monday, January 30, 2012 at 3:04 AM, "Martin v. Löwis" wrote:
> > > > -1. There are plenty of ways to check whether the file was modified if
> > > > you already have a copy of it. Users just need to accept that files may
> > > > change, and package authors need to accept that users may retain old
> > > > copies of a file even after they replaced it.
> > > >  
> > >  
> > > I don't always have a copy of the file, I might only have a reference
> > > such as slumber==0.3.0.  
> > >  
> >  
> >  
> > The better. A responsible author, when replacing an existing file,
> > should make sure that it is reasonably compatible with the previous
> > copy of the file. E.g. the update may include corrected typos or include
> > files that the previous copy didn't include; the previous copy may have
> > actually not worked at all in some circumstances.
> >  
> > Now, it may be that the author does break your code by mistake when
> > replacing a file. You should then report that to the author, asking
> > him to restore the original file and be more careful in the future.
> >  
> > Regards,
> > Martin
> >  
> >  
> >  
>  
>  

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