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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>> 
>> 
>> On Feb 9, 2013, at 6:13 PM, Stephen Thorne <[email protected]> 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
>> [email protected]
>> http://mail.python.org/mailman/listinfo/catalog-sig
>> 
> _______________________________________________
> Catalog-SIG mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/catalog-sig



-- 
Giovanni Bajo   ::  [email protected]
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it





Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

Reply via email to