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

Christian Heimes christian at python.org
Wed Feb 6 13:16:09 CET 2013

Am 05.02.2013 22:13, schrieb Giovanni Bajo:
> The theoretical attack I can think of is that an attack that has stolen the user's credential, could re-upload a previous version of a package that has been removed/deprecated. I think that PyPI already mandates monotonic version number increases, but I can see this check being buggy or lifted in the future, so I wouldn't overload it with a security meaning. So, I agree the timestamp check makes sense.

I also think that pip always install the latest final release unless you
specify a version number. This problem needs to be addressed in the
design specs.

> I fail to understand what this signing buys us, basically because I fail to parse the line "Without the PyPI signature a downloader would have to trust a key for all available packages". Can you please elaborate, maybe in terms of attacks that are prevented?

I altered and modified this sentence so often that I might have
destroyed it. :/

In order to verify and validate a signature, you have to answer two

a) Do I trust the owner of a key?
b) Is the owner of the key related to the signed package?

GPG is only able to establish a level of trust between you and the key
owner. When you import and sign a key then you trust the key for all

With PyPI's signature under the user's signature and the package's
metadata you can check that PyPI has trusted the user at that point in
time. PyPI acts as a notary and attest the correctness of the
relationship between uploader and package.

>> - Should the tool chains use its own key rings for verification instead
>>  of the user's default keyring? A tool like
>> http://man.he.net/man8/apt-key might be useful.
> I don't see what it buys us, and it makes things harder to handle in my opinion.

Personally I don't want to mix my personal key ring with the keys for
Python package verification. I also like to distribute my trust db and
public keys to servers but not my personal contacts.


More information about the Catalog-SIG mailing list