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

[Daniel Holth]

On Mon, Nov 19, 2012 at 4:34 PM, Tarek Ziadé <tarek at ziade.org> 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 ?
>

You should consider reading up on the design of TUF: The Update Framework (
https://www.updateframework.com/). They have designed a security system for
Python packages.

One solution to the key revocation problem is to have two signatures, a
timestamp from PyPI along with a signature from the publisher. The package
is only valid if it has a valid publisher signature along with a timestamp
that is within the validity period of the publisher's signing key.

In other words, if I publish a package in October but revoke my public key
in November, the package is still valid because PyPI asserts it was signed
before the key was revoked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20121119/577414cd/attachment.html>