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 questions: 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 packages. 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. Christian _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
