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

[Giovanni Bajo]

Il giorno 05/feb/2013, alle ore 20:21, Christian Heimes <christian at python.org> ha scritto:

> Hello,
> 
> I like to discuss my proposal for a package signing and verification
> process. It's just a brief draft and not a final document. (Credits to
> my friend Marcus Brinkmann for additional insights).
> 
> 
> Package maintainer registers PGP key
> ------------------------------------
> 
> Package owners and maintainer that like to sign their packages must
> register their PGP/GPG key in front. The key must be registered with a
> public key server (e.g. launchpad) and must contain an identity that
> corresponds with her email address. Also the key must follow certain
> standards (no insecure algorithms / key length) and be valid (not
> expired or revoked). A user can register multiple GPG keys.
> 
> process:
> - User must provide the full fingerprint (not the short key id).
> - PyPI retrieves the key from a key server.
> - PyPI verifies the key's properties.
> - PyPI sends an encrypted mail to the user which contains an
>   activation link for the key.
> - User decrypts the mails with her private key and actives
>   the key with the link.
> 
> result:
>  PyPI has a verified GPG key of the package maintainer.

I think the last two steps above are unnecessary. Security-wise, you are just verifying that the user is not lying to you about her own GPG keys, but I don't see why you shouldn't trust her (assuming that she is authenticated on PyPI, through her password/oauth, through HTTPS). Currently, PyPI already allows an user to specify her GPG key fringerprint, and I believe that's sufficient.

As an additional note: PyPI might expose its own GPG keyserver. I don't think it's necessary though.

> Package maintainer signs and uploads a package
> -----------------------------------------------
> 
> The procedure doesn't change excepet that PyPI may revoke a signature
> (more on that later). The upload process must use HTTPS and the SSL
> server cert is validating against a CA cert bundle.
> 
> result:
>  uploader has uploaded her content and signature through a
>  safe channel that protects against password sniffing
>  and reply attacks

The only note here is that we might eventually want to pin the CA certificate somehow.

> PyPI accepts and validates upload
> ---------------------------------
> 
> As first step PyPI validates the signature and the user's key:
> 
> - Is the signature valid and matches the uploaded content?
> - Does the signing key match a registered GPG key of the user?
> - Is the user's key still valid (expiration, revocation)
> - Is the timestamp of the signature within a sensible range
>   (plus minus a couple of hours?)
> 
> result:
>  PyPI has a validated signature that matches the user's
>  settings. The time check adds an additional countermeasure
>  against replay attacks,

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.

> PyPI signs the signature
> ------------------------
> 
> Here comes the tricky part of the process. Bare with me!
> 
> PyPI generates a metadata file that contains:
> 
>  - timestamp of the upload
>  - metadata of the user (id, name, email ...)
>  - metadata of the package (excerpt of PKG-INFO)
>  - the user's signature of the uploaded content as ASCII armor
> 
> Then PyPI signs the metadata files with its OWN key. It's crucial to
> acknowledge that PyPI does NOT sign the uploaded content! It just signs
> the user's signature and the package + user metadata. PyPI's signature
> does NOT state anything about the file's content or the correctness of
> the containing code.
> 
> Why does PyPI sign the package then? PyPI is the only instance that can
> verify the relationship between an uploader and a package's content.
> PyPI's signature promises that PyPI trusts the user to upload and sign
> the package *at this very moment*. With this signature a downloader can
> verify that the uploader was a registered maintainer of the package at
> this very moment. Without the PyPI signature a downloader would have to
> trust a key for all available packages.
> 
> result:
>  The combined file (inner layer: metadata, user's signature,
>  outer layer: PyPI signature) certifies that the uploader
>  has a relationship to the project on PyPI

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?


> User installs package
> ---------------------
> 
> process:
> - <tool> retrieves the package and the combined signature file (PyPI's
> signature, metadata file and embedded signature of the uploader)
> - <tool> optionally downloads missing GPG keys from PyPI
> - <tool> verifies PyPIs signature of the metadata file and then the
>   uploader's signature of the content
> - on success <tool> install the package
> 
> The verification process needs some interaction with the downloader. She
> must accept and establish a trust level with each key. This needs to be
> discussed in detail.
> 
> 
> Open points
> -----------
> 
> - Should we allow multiple users for a single GPG key (e.g .team keys)?

No, but I think it makes sense to force a package to be signed by a minimum number of keys.
> 
> - 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.

> - An uploader must be able to revoke her keys from PyPI without
>  access to her private key.

This is already implemented, an user can modify her listed GPG fingerprint. This is not different from, eg:, the page that allows a github user to install and revoke SSH keys.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

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





-------------- 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/20130205/73a847f0/attachment.bin>