On Mon, Sep 3, 2012 at 2:15 AM, Ronald Oussoren email@example.com wrote:
On 22 Aug, 2012, at 4:52, Daniel Holth firstname.lastname@example.org wrote:
I've made what I think is exciting progress on the digital signatures design for wheel (updated built/binary packages for Python; intended to replace egg). The insight is that we can overload the "extras" syntax as a convenient way to mention the public key we expect:
Why this hack instead of providing explict syntax for this?
It's because it can be made to be backwards-compatible. Declare that your package provides the extra "ed25519=key" and non-signature-verifying setuptools won't complain. I like the idea of using array indexing  for "which package? the one signed with a particular key."
Also the format doesn't seem to have any way to verify the validity of the signing key, the documentation even says that "key distribution is out of scope for this spec". That's odd for feature that's intended to add security.
Why did you decide to use JSON Web Signatures instead of PGP signatures, or even X.509 signatures? With the latter two the key distribution problem is already solved, and PGP signatures are used a lot in the opensource world.
I wanted to use Ed25519, an elliptic-curve signatures system that has 32-byte public keys and a very fast (~100k cycle) implementation. I wanted to be able to generate throwaway keys in 2.5 milliseconds and use them to verify transfers between a build server and an installation, and have keys represent the build server or the package, not necessarily a person. I wanted to include the entire signing and verifying system in Python instead of relying on an external package.
Currently so few Python packages are signed that popular opinion is that signing isn't supported at all (it is). I think part of the problem is that PGP is totally inconvenient. A new system gives us the opportunity to try to make signing so effortless that publishers are more likely to provide us with signed packages.
Key distribution is outside the scope of the wheel spec which just says how signatures are included in the file. I think we are figuring out some elegant solutions though, the first being "a PGP-signed e-mail containing package[ed25519=key] lines" (distributed by the publisher of a Python application that has dependencies). Signed wheel archives include the verifying key as part of the signature. Maybe PyPI will eventually provide a place for it too.