[tahoe-dev] [Distutils] wheel file signatures scheme

Daniel Holth dholth at gmail.com
Mon Sep 3 11:24:32 UTC 2012


On Mon, Sep 3, 2012 at 2:15 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 22 Aug, 2012, at 4:52, Daniel Holth <dholth at 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


More information about the tahoe-dev mailing list