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

Giovanni Bajo rasky at develer.com
Thu Feb 7 11:51:36 CET 2013


Il giorno 07/feb/2013, alle ore 11:45, Ronald Oussoren <ronaldoussoren at mac.com> ha scritto:

> 
> On 7 Feb, 2013, at 11:25, Giovanni Bajo <rasky at develer.com> wrote:
> 
>> Il giorno 07/feb/2013, alle ore 11:08, Ronald Oussoren <ronaldoussoren at mac.com> ha scritto:
>> 
>>> 
>>> On 6 Feb, 2013, at 22:15, Daniel Holth <dholth at gmail.com> wrote:
>>> 
>>>> On Wed, Feb 6, 2013 at 4:05 PM, Jesse Noller <jnoller at gmail.com> wrote:
>>>> 
>>>> 
>>>> On Wednesday, February 6, 2013 at 4:02 PM, Donald Stufft wrote:
>>>> 
>>>> > On Wednesday, February 6, 2013 at 4:01 PM, Vinay Sajip wrote:
>>>> > > M.-A. Lemburg <mal <at> egenix.com (http://egenix.com)> writes:
>>>> > >
>>>> > > > Try gnupg-w32cli which is really easy to install and doesn't
>>>> > > > get in your way:
>>>> > > >
>>>> > > > http://lists.gnupg.org/pipermail/gnupg-announce/2012q1/000313.html
>>>> > >
>>>> > > Or, to fast-track to the binaries, look in here:
>>>> > >
>>>> > > ftp://ftp.gnupg.org/gcrypt/binary/
>>>> > >
>>>> > > As MAL says, installation with these installers is fairly painless.
>>>> > Average end user: "What's a GPG"
>>>> 
>>>> Or even those of us familiar and using it day to day "Oh Jeez not again"
>>>> 
>>>> That is why the original wheel signing design uses no GPG, a system that has proven to be unused in practice. Hypothesis: something different cannot possibly be less successful. Instead, it uses raw public key signatures implemented with very concise Python code. It might even automatically generate one for you if you have none. Wheel's scheme would be perfect for Plone which distributes long lists of all its dependencies, as they would just add the publisher key as an argument to each dependency. A new maintainer might receive a copy of the private key as keys are meant to be plentiful and contain no extra information such as e-mail addresses.
>>>> 
>>>> Using ssh-agent to produce signatures with the user's ssh keys is another option.
>>>> 
>>>> There is a complete Python implementation of TLS out there.
>>> 
>>> Implementing enough of PGP in python to do clear signing and verification shouldn't be too hard either :-)
>> 
>> I'm -1 on that; installing GPG is easy on all major development platforms (including Windows), and we can provide a simple tutorial for the few required steps.
> 
> I agree. The primary reason to mention a python implementation is that PGP/GPG shouldn't be excluded just because it is an external C tool and not a 3 line python algoritm.
> 
>> 
>>> 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. 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).

> 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.

> It would be nice if the system uses well established protocols instead of green-field development.  I know just enough of security systems to be dangerous, and one thing I do try to keep in mind when I do have to do anything security related is that it is a lot easier to create almost-but-not-quite secure protocols/architectures than actual secure ones.

Yes. We are not designing any custom protocol. The additional layer of GPG signatures is just made through regular GPG signature files being generated, uploaded through HTTP POSTs and downloaded with HTTP GETs.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

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





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


More information about the Catalog-SIG mailing list