Il giorno 07/feb/2013, alle ore 11:59, "M.-A. Lemburg" <[email protected]> ha scritto:
> Sorry, if this has already been mentioned, but we could make GPG > signing very user friendly for the PyPI users by: > > - having the PyPI server verify the uploaded file against the > registered GPG key of the uploader > > - have the PyPI server sign the uploaded file using its own > key (so you have two .asc signature files per upload - one coming > directly from the uploader and another one from the PyPI server) > > - have package managers verify the downloaded file against the > signature applied by PyPI > > Package managers would only have to know the PyPI public key > for this to work. > > Users who want to apply an extra check, could also verify > the uploader's .asc signature file, but this would require > downloading and installing the uploader's GPG key; in return > for the extra work, they'd get two way verification, though. > > The concept is based on trust: PyPI trusts the uploader provided > that s/he is using the registered GPG key. Package managers (and > users) trust PyPI. This has been already proposed (first mail in this thread), but I still fail to see, from a security perspective, what the additional signature performed by PyPI buys us. It is complicated and delicate to handle on the server side, it would require key management, rotation, etc. and I still don't see what is the point. As long as PyPI tells the client "key ABCD1234 is authoritative for package django", and it tells it through a (verified) SSL connection, I don't think the signature itself is useful. Can you please describe an attack that can be mounted against PyPI/pip that is prevented by having this additional signature? -- 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
