[Catalog-sig] [Draft] Package signing and verification process

[Ronald Oussoren]

On 7 Feb, 2013, at 11:51, Giovanni Bajo <rasky at develer.com> wrote:

> 
>> 
>>> 
>>>> What I haven't seen (or have overlooked) in the entire discussion is what we're trying to protect against.  The thread kicked of due to a report of how to perform MITM attacks against PyPI, but it seems that some of the proposals want to provide much more security than that.  Without a clear description of a threat model it is hard to evaluate if proposals actually fix anything.  
>>> 
>>> Basically, we are trying to define a system that can survive some level of compromisation of PyPI, and at the same time allow PyPI to use a third-party CDN without having to trust it.
>>> 
>>> Moreover, some people might want to get to a point where they disable trust on PyPI totally but they still want to be able to install packages off it.
>> 
>> The system should also be somewhat userfriendly, having to accept a new key for every package will likely not increase security as much as it would seem at first glance because a lot of users will just accept the new key without seriously looking at it.
> 
> Yes, and in fact that's not what we are designing. I understand the thread is long, but I suggest to at least skim through it.

I did skim through it and one of the proposals did mention that users should have to accept every new key (IIRC the one using the distrust tool/framework).

> The basic idea is that the tool will have to trust PyPI when it says that key ABCD1234 is authorized to sign package "foo". So PyPI would be the central authority of package signature trust. This reaches the compromises of perfect user interface (no questions asked) and protection against a few types of attacks (write access to the file area, pypi credentials stolen).

That should work (both security wise and for the UI)

> 
>> What I'd like to see is a system where I can be reasonably sure that when I do "<tool> install <package>" I'll get that package (and its dependencies) of PyPI, without a MITM interfering and with some assurance that the package  is uploaded by an authorized user and the contents is what that user wants it to be.   Anything beyond that, such explicitly trusting individual developers might be useful in the long run but has a clear risk of making package installation more complicated.
> 
> Yes. Again, that's what we are designing.

Great. Thanks for confirming that.

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/dcea5cd7/attachment.html>