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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
This line in a pip-style requires.txt specifies that we want to install package, the normal optional dependency "extra" and that we expect it to have a valid signature made with the mentioned ed25519 public key.
Distribute your application, assemble its requirements in this format, sign that file, and Bob's your uncle -- your users can install from that file and know that the requirements they download have the same publishers as the packages you developed with. This is far more powerful than a file hash because it is valid for more than one version of the package.
For backwards compatibility, packages can say they provide the extra ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA (adding no dependencies) and easy_install should parse and ignore it, installing from an unsigned egg or source distribution because it doesn't know about wheels.
bdist_wheel will be updated to always sign the wheels it generates if possible, making up a new signing key if one is not stored on the building machine. That way signed wheels will be commonplace, and the remaining problem is simply to decide which signing keys you would like to trust.
wheel now includes a command line tool `wheel sign wheelfile.whl` that adds a digital signature to a wheel file.
http://wheel.readthedocs.org/en/latest/index.html#signed-wheel-files
On 22/08/12 03:52, Daniel Holth 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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
I missed this when you first posted it. I like it a lot.
The signature would be on the wheel binary package file?
The file "record" inside the archive is signed. On Sep 1, 2012 1:42 PM, "David-Sarah Hopwood" david-sarah@jacaranda.org wrote:
On 22/08/12 03:52, Daniel Holth 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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
I missed this when you first posted it. I like it a lot.
The signature would be on the wheel binary package file?
-- David-Sarah Hopwood ⚥
On 22 Aug, 2012, at 4:52, Daniel Holth dholth@gmail.com 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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
Why this hack instead of providing explict syntax for this?
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.
Ronald
http://wheel.readthedocs.org/en/latest/index.html#signed-wheel-files _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Sep 3, 2012 at 2:15 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 22 Aug, 2012, at 4:52, Daniel Holth dholth@gmail.com 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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
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.
Thanks,
Daniel
On 2012-09-03 11:24:32 +0000, Daniel Holth said:
On Mon, Sep 3, 2012 at 2:15 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 22 Aug, 2012, at 4:52, Daniel Holth dholth@gmail.com 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:
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
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.
Good answer :-)
Thanks,
Daniel
participants (4)
-
Alex Clark -
Daniel Holth -
David-Sarah Hopwood -
Ronald Oussoren