[Catalog-sig] getting the public key when --sign is used

M.-A. Lemburg mal at egenix.com
Tue Nov 20 09:41:03 CET 2012


On 19.11.2012 22:34, Tarek Ziadé wrote:
> On 11/19/12 7:55 PM, M.-A. Lemburg wrote:
>> On 19.11.2012 19:37, Tarek Ziadé wrote:
>>> Hey
>>>
>>>
>>> I am currently writing a small script to verify that the gpg signature is correct when the --sign
>>> option
>>> is used with the Distutils upload command, and I was wondering why we don't publish the public key
>>> alongside the .asc file.
>>>
>>> Right now, unless I missed something, to verify a signature the user has to manually get the public
>>> key before she
>>> can control the tarball.
>>>
>>> Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive
>>> file
>>> and the .asc file on PyPI ?  (since we don't have a notion of team/users etc.)
>>
>> Doesn't that cause problems when revoking a public key ?
>>
> That problem still exists as things are today at PyPI -if you sign a package you get an .asc file
> uploaded and
> you need to tell people where is your public key.
> 
> If you change your key, the asc file is not valid anymore.
> 
> I am not sure what would be the best way to do this: maybe we should allow people to update the asc
> files ?

There are two things to consider when revoking a key (e.g. because
it got compromised):

1. You need to tell users that the key is revoked

2. You need to be able to resign packages that had been signed using
   the revoked key.

For the first requirement, I think PyPI should not try to create a
new PKI, but instead rely on the existing public key servers that
PGP and GPG both know how to work with. Key revocation is part of
this infrastructure, along with many other features that we don't
really want to duplicate in PyPI :-)

For the second requirement, updating the .asc file would be
a solution. Alternatively, the packagers could check the revocation
date and then still allow packages to be installed which were signed
before the revocation happened.

Note that the second requirement may also be needed for expired
keys - unless packagers choose to ignore such expiration, and
accept packages that were signed with a then valid key. This is
how Windows treats expired certificates on installers.

For both methods involving checking the packaging time, you do
need to use a timestamp server to make things waterproof
(see e.g.
http://stackoverflow.com/questions/2872105/alternative-timestamping-services-for-authenticode).

Aside: These discussions appear a bit academic to me, since
the signatures only add a small bit of extra security to the
whole setup (protection against tampering with the distribution
files on the PyPI server and an extra password entry on the
uploader's side), while making the system a lot more complex.
Apart from the academic challenge, I wonder whether it's worth
the trouble :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 20 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the Catalog-SIG mailing list