Il giorno 05/feb/2013, alle ore 20:21, Christian Heimes <[email protected]> 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 :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
