[Catalog-sig] PyPI and setuptools

[Jesse Noller]

Python dev, and the PSRT is aware that the ssl work needs to be taken care of, in core. 3.3 is already doing things mostly right - those need to be back ported.

I need to bring this up to the security team; it was part of the working document Christian, Donald stufft, Brett Cannon, I and others have been discussing things on to triage the immediate issues

On Feb 9, 2013, at 7:50 PM, Giovanni Bajo <rasky at develer.com> wrote:

> To clarify, the specific item that Justin mentioned (urlllb drop-in replacement) is related to a single task (#2) out of 13 in my document. That task is also being separately handled by pip (https://github.com/pypa/pip/pull/791) and it's almost ready to merged and fixed. The urllib replacement can still be interesting for easy_install though.
> 
> TUF is a more complex framework, and is alternative to several items in my proposal, as far as I can tell. I don't know TUF well enough, though.
> 
> BTW, I would like that, instead of having a urllib replacement that does SSL the way it should be done, the standard urllib did it. So maybe Justin should push it to python-dev instead.
> 
> Il giorno 10/feb/2013, alle ore 00:43, Jesse Noller <jnoller at gmail.com> ha scritto:
> 
>> Is what you just said part of Giovanni's proposal he sent for review?
>> 
>> On Feb 9, 2013, at 6:40 PM, Justin Cappos <jcappos at poly.edu> wrote:
>> 
>>> We're hoping to be able to fix this by interposing on network communications by these tools.   The basic idea is that we'll have a replacement for urllib, urllib2, etc. that adds and validates security cleanly.   (Note the replacements will only be used in python package managers.)   TUF ( https://www.updateframework.com/ ) will correctly validate security metadata and only pass validly signed information to the package manager for installation.   
>>> 
>>> So the hope is that other than a few lines of code that import the alternative for urllib, urllib2, etc. there won't be any changes.   We will be maintaining the security code as a separate project (TUF is used by things other than Python package managers) and will be constantly improving it.
>>> 
>>> Anyways, I won't be able to attend, but I will try to get a student to show a demo in the hallways at PyCon to show what we mean...
>>> 
>>> Thanks,
>>> Justin
>>> 
>>> 
>>> On Sat, Feb 9, 2013 at 6:28 PM, Jesse Noller <jnoller at gmail.com> wrote:
>>>> 
>>>> 
>>>> On Feb 9, 2013, at 6:13 PM, Stephen Thorne <stephen at thorne.id.au> wrote:
>>>> 
>>>> > Hello,
>>>> >
>>>> > One of my concerns with the recent pip dramas that have seen some excellent and timely action from catalog-sig and others, is that 'setuptools' is still widely distributed and used instead of distribute/pip.
>>>> 
>>>> Well, lets back up: these aren't pip specific problems: just about every client side tool for installing from pypi suffers from lax security.
>>>> 
>>>> >
>>>> > Setuptools either needs to be sunset, notices put on pypi, warnings given to its users, out of linux distros, or it has to upgraded to be feature compatible with the security updates.
>>>> >
>>>> > That's a strong statement I've made, but I feel strongly that something has to be done. I would like to solicit opinions here before an action plan is composed.
>>>> 
>>>> This is a bit of a question mark to me: the reality is that easy_install/setup tools usage is probably still dramatically higher than that of more modern tooling. That, and AFAIK, there are still features of them that the alternatives do not support (binary eggs, which are a must for windows).
>>>> 
>>>> This leaves us at the point where they can not be sunset unless the "other tools" grow the features of setuptools/easy_install or we (the collective we) take on the burden of updating that tool chain to support secure installations.
>>>> 
>>>> Just patching them for security fixes seems like an "easy" task; the bigger question is how to do that only without further feature addition and getting a release out the door?
>>>> 
>>>> Jesse
>>>> _______________________________________________
>>>> Catalog-SIG mailing list
>>>> Catalog-SIG at python.org
>>>> http://mail.python.org/mailman/listinfo/catalog-sig
>> _______________________________________________
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
>> http://mail.python.org/mailman/listinfo/catalog-sig
> 
> 
> 
> -- 
> Giovanni Bajo   ::  rasky at develer.com
> Develer S.r.l.  ::  http://www.develer.com
> 
> My Blog: http://giovanni.bajo.it
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130209/7c6ca2b9/attachment-0001.html>