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 <[email protected]> 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 <[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 > > > > >
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
