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

Jesse Noller jnoller at gmail.com
Thu Feb 7 11:58:15 CET 2013



On Feb 7, 2013, at 5:45 AM, Giovanni Bajo <rasky at develer.com> wrote:

> Il giorno 07/feb/2013, alle ore 11:32, Jesse Noller <jnoller at gmail.com> ha scritto:
> 
>> 
>> 
>> On Feb 7, 2013, at 5:25 AM, 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.
>> 
>> That tutorial would have to be amazingly easy, and GPG could never be a hard requirement. GPG is still annoying, clunky and painful enough that it would just become a nuisance and people would move elsewhere.
> 
> I think you are overestimating what needs to be done for GPG to be useful for pip:

Not really - I know that if we're going to do crypto, the first rule of crypto is "don't make your own crypto" - I've just worked with pgp/openpgp enough to realize its usability is astoundingly atrocious.


> 
>   * For package installation: just have GPG installed on the system path, no configuration is required.
>   * For package upload: creation of a key (gpg --gen-key) and maybe upload to a keyserver, if we don't want PyPI to serve them. It's a short tutorial of 1 or 2 commands.
> 
> That's it. What brings us:
> 
> 1) We can use CDNs without having to trust them
> 2) We can survive attacks with write access to the file area of PyPI
> 3) We can survive PyPI credentials stolen from a maintainer (or bruteforced)
> 
> While I believe it should eventually be mandatory, I'm not trying to argue that now. I'm perfectly fine to have it implemented first, and then we can evaluate the actual impact on the users, instead of having a generic fear of a painful process.
> -- 
> 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/e35a58c3/attachment-0001.html>


More information about the Catalog-SIG mailing list