[Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security

[Giovanni Bajo]

Il giorno 10/feb/2013, alle ore 13:54, Nick Coghlan <ncoghlan at gmail.com> ha scritto:

> On Sun, Feb 10, 2013 at 10:36 PM, Jannis Leidel <jannis at leidel.info> wrote:
>> 
>> On 10.02.2013, at 05:44, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 
>>> On Sun, Feb 10, 2013 at 7:23 AM, Giovanni Bajo <rasky at develer.com> wrote:
>>>> Hello,
>>>> 
>>>> my proposal for fixing PyPI and pip security is here:
>>>> https://docs.google.com/a/develer.com/document/d/1DgQdDCZY5LiTY5mvfxVVE4MTWiaqIGccK3QCUI8np4k/edit#
>>>> 
>>>> I tried to sum up the discussions we had here last week, elaborating on Heimes' proposal by simplifying it where I thought the additional steps wouldn't guarantee additional security. At this point, the proposal does not include a central, uber-master online GPG signing key to be stored on PyPI, which is IMO quite hard to handle correctly.
>>> 
>>> I think the parts related to improving the HTTPS/SSL based security
>>> are solid, but for the other aspects of secure updates, integrating
>>> TUF (https://www.updateframework.com/) into the PyPI based
>>> distribution infrastructure sounds like the best available option for
>>> enhancing the end-to-end integrity checking. TUF has a comparatively
>>> well-developed threat model, and systematically covers many of the
>>> attack vectors discussed in the past few day (including provision of
>>> old, known vulnerable, versions).
>> 
>> Would you mind explaining why TUF is good?
> 
> The main benefit in my mind is that it isn't a from-scratch design of
> a secure update infrastructure. Instead, it's a project that was
> started in order to resolve some security holes found in Tor's already
> robust automatic update mechanism, then proceeded from there into
> updates to yum, yast, apt, etc (i.e. the distro update mechanisms that
> are vetted by the security teams of the various Linux vendors).

Notice that all those big-profile names don't use TUF, as far I can tell. I don't know exactly what it's been fixed with the help of the TUF guys, but it's not that it's a world-deployed standard model.

> However, the design itself also seems sensible, and is able to provide
> its security guarantees even if you're *not* using SSL certs to
> protect the in-flight traffic (thus meaning that the SSL
> infrastructure in the near term will become a matter of providing
> defence-in-depth, rather than being a required part of the security
> scheme).

The same applies to my design, and to any design that achieves end-to-end integrity, but the point is still only theoretical because TUF doesn't solve the problem of trust. TUF designers will have to come up to a trust model for PyPI, which is what 50% of my document is about. 

> I trust our collective ability to make TUF sufficiently easy to use as
> part of Python's packaging infrastructure a *lot* more than I trust
> our collective ability to come up with a from-scratch distribution
> scheme that is both usable *and* secure.


I would like to see existing large-scale/high-profile deploys of TUF. Are there any? Otherwise the argument "TUF already exists, let's use it" is a bit weak.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/777af976/attachment.bin>