[tahoe-dev] wheel file signatures scheme

Daniel Holth dholth at gmail.com
Wed Aug 22 02:52:04 UTC 2012


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


More information about the tahoe-dev mailing list