[Catalog-sig] PyPI and setuptools

[Justin Cappos]

No, it's not.   We're working on something separate that is based on some
of the security architecture changes we got pushed into apt, YUM, YaST,
Pacman, etc.   It's designed with help from the Tor folks after we
disclosed some security issues in their software updater.

I'd need to look at Giovanni's proposal in detail (and I don't have time
until late this month at the earliest), but there are a lot of really
subtle bugs and issues one can get into.   That's why we're trying to push
for a universal framework instead of having every project roll their own...

Thanks,
Justin


On Sat, Feb 9, 2013 at 6:43 PM, Jesse Noller <jnoller at gmail.com> wrote:

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130209/dc24ceae/attachment.html>