On 7 Feb, 2013, at 11:51, Giovanni Bajo <[email protected]> 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
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
