headers
Terry Reedy | 1 Feb 2012 01:40
Picon
Favicon

Re: Proposal: close the PyPI file-replacement loophole

On 1/31/2012 6:43 PM, Donald Stufft wrote:
> I don't think anyone is arguing that it's not occasionally useful. The
> question to answer is the occasional usefulness worth the risks that
> come with it. In my opinion the small utility (being able to correct a
> borked packaging job) is not worth the risks to both my applications
> stability, and the security of my entire system.

The question is whether, on each issue, PyPI should be optimized for 
authors (who provide their modules for free) or for users. Both choices 
are defensible. However, if all choices are made in favor of users, 
there will very likely be fewer things uploaded or even listed, which is 
not favorable for users.

It is hard to take your security concerns too seriously when you 
consistently ignore security suggestions. Prohibiting deletion or 
replacement by authors will give you no protection against the site 
being compromised by other means, whereas the suggestions you ignore would.

--

-- 
Terry Jan Reedy
Permalink | Reply | 6 comments |
headers
Donald Stufft | 1 Feb 2012 01:41
Picon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

Which suggestions did I ignore?

On Tuesday, January 31, 2012 at 7:40 PM, Terry Reedy wrote:

On 1/31/2012 6:43 PM, Donald Stufft wrote:
I don't think anyone is arguing that it's not occasionally useful. The
question to answer is the occasional usefulness worth the risks that
come with it. In my opinion the small utility (being able to correct a
borked packaging job) is not worth the risks to both my applications
stability, and the security of my entire system.

The question is whether, on each issue, PyPI should be optimized for
authors (who provide their modules for free) or for users. Both choices
are defensible. However, if all choices are made in favor of users,
there will very likely be fewer things uploaded or even listed, which is
not favorable for users.

It is hard to take your security concerns too seriously when you
consistently ignore security suggestions. Prohibiting deletion or
replacement by authors will give you no protection against the site
being compromised by other means, whereas the suggestions you ignore would.

--
Terry Jan Reedy

_______________________________________________
Catalog-SIG mailing list
 

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Permalink | Reply | 2 comments |
headers
Donald Stufft | 1 Feb 2012 01:43
Picon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

and by all means, a lot of things aren't protected when the server itself is compromised, we should go ahead and disable any of those that are even mildly annoying too.

On Tuesday, January 31, 2012 at 7:40 PM, Terry Reedy wrote:

On 1/31/2012 6:43 PM, Donald Stufft wrote:
I don't think anyone is arguing that it's not occasionally useful. The
question to answer is the occasional usefulness worth the risks that
come with it. In my opinion the small utility (being able to correct a
borked packaging job) is not worth the risks to both my applications
stability, and the security of my entire system.

The question is whether, on each issue, PyPI should be optimized for
authors (who provide their modules for free) or for users. Both choices
are defensible. However, if all choices are made in favor of users,
there will very likely be fewer things uploaded or even listed, which is
not favorable for users.

It is hard to take your security concerns too seriously when you
consistently ignore security suggestions. Prohibiting deletion or
replacement by authors will give you no protection against the site
being compromised by other means, whereas the suggestions you ignore would.

--
Terry Jan Reedy

_______________________________________________
Catalog-SIG mailing list
 

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Permalink | Reply | 0 comments |
headers
Terry Reedy | 1 Feb 2012 01:46
Picon
Favicon

Re: Proposal: close the PyPI file-replacement loophole

1. Record and check md5 hash on all downloads.
2. Redistribute files yourself (if license allows).

Ignore in sense of not respond why not adequate alternative to your request.

It is confusing.
Please do not top post

On 1/31/2012 7:41 PM, Donald Stufft wrote:
> Which suggestions did I ignore?
>
> On Tuesday, January 31, 2012 at 7:40 PM, Terry Reedy wrote:
>> It is hard to take your security concerns too seriously when you
>> consistently ignore security suggestions. Prohibiting deletion or
>> replacement by authors will give you no protection against the site
>> being compromised by other means, whereas the suggestions you ignore
>> would.
--

-- 
Terry Jan Reedy
Permalink | Reply | 1 comment |
headers
Donald Stufft | 1 Feb 2012 01:58
Picon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

On Tuesday, January 31, 2012 at 7:46 PM, Terry Reedy wrote:
1. Record and check md5 hash on all downloads.
2. Redistribute files yourself (if license allows).

Ignore in sense of not respond why not adequate alternative to your request.

It is confusing.
Please do not top post

On 1/31/2012 7:41 PM, Donald Stufft wrote:
Which suggestions did I ignore?

On Tuesday, January 31, 2012 at 7:40 PM, Terry Reedy wrote:
It is hard to take your security concerns too seriously when you
consistently ignore security suggestions. Prohibiting deletion or
replacement by authors will give you no protection against the site
being compromised by other means, whereas the suggestions you ignore
would.
--
Terry Jan Reedy

_______________________________________________
Catalog-SIG mailing list
Email client defaults to top posting.

1. Pip doesn't support this that i'm aware of. I'm looking at the possibility of adding that to pip but currently I believe it would require zc.buildout.
2. I already do this. This is currently the best option available to people but it is a poor option. It essentially equates too "Well Yes PyPI is insecure by design, if you want security don't use it."

I'm also not arguing for just myself. I use the term "me" and "my" but they are placeholders for "anyone using this system". Unless you think that anyone wanting to not be vulnerable to their app breaking without warning, and without anything changing on their end (besides a new install) and wanting to not be vulnerable to the security issues should just "not use PyPI" which is completely unreasonable.

The *best* place to fix this is in PyPI. That way the fix to these vulnerabilities will be applied for *everyone*. Yes I can work around it on a personal level, but that doesn't help the community, it only helps myself.
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Permalink | Reply | 0 comments |
headers
Jim Fulton | 1 Feb 2012 02:14
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

On Sun, Jan 29, 2012 at 6:47 PM, Richard Jones <r1chardj0n3s <at> gmail.com> wrote:
...
> Your thoughts?

I appreciate Donald's persistence. :)

I'm still +1

Jim

--

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Permalink | Reply | 0 comments |
headers
Alex Clark | 1 Feb 2012 02:45
Favicon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

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.

Alex

>
>
>       Richard

--

-- 
Alex Clark · http://pythonpackages.com
Permalink | Reply | 33 comments |
headers
Toshio Kuratomi | 1 Feb 2012 03:08
Picon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

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

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Permalink | Reply | 32 comments |
headers
Richard Jones | 1 Feb 2012 03:30
Favicon

Re: Proposal: close the PyPI file-replacement loophole

On 1 February 2012 13:08, Toshio Kuratomi <a.badger <at> gmail.com> wrote:
> 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.

That facility does not exist.

I believe it shouldn't be difficult in the current pypi code to allow
a re-run of the file_upload action (either through the form or through
distutils) where the signature is present and attach the signature to
the existing file, assuming they file accompanying the signature
upload is identical to the existing file.

     Richard
Permalink | Reply | 31 comments |
headers
Yuval Greenfield | 1 Feb 2012 08:12
Picon
Gravatar

Re: Proposal: close the PyPI file-replacement loophole

+1 on removing this security loophole in any of the ways suggested here.

Ps I don't think it's "uploaders" vs "downloaders" utility as I'm pretty sure the uploaders download from pypi as well. And even if it was so, boosting the trustworthiness of pypi is a win for both sides.

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG <at> python.org
http://mail.python.org/mailman/listinfo/catalog-sig
Permalink | Reply | 30 comments |

Gmane