[Distutils] Removing wheel signing features from the wheel library

Wes Turner wes.turner at gmail.com
Thu Mar 22 17:56:22 EDT 2018


On Thursday, March 22, 2018, <alex.gronholm at nextday.fi> wrote:

> to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti:
>
>
>
> On Thursday, March 22, 2018, Daniel Holth <dholth at gmail.com> wrote:
>
> The feature was a building block that was intended to be used in much the
> same way that SHA package hashes are used, providing similar security to
> the ssh-style TOFU model, but less security than other imaginable public
> key systems. The idea was that it could provide more security in practice
> because the signatures could exist and be present with the archive, unlike
> gpg which provides loads of security in theory only. Unfortunately wheel
> signatures were never built up. I don't think anyone was tricked into
> believing the primitive provided security on its own.
>
>
> The hashes serve as file integrity check but provide no assurance that
> they are what the author intended to distribute because there is no
> cryptographic signature.
>
> File hashes help detect bit flips -- due to solar flares -- in storage or
> transit, but do not mitigate against malicious package modification to
> packages in storage or transit.
>
>
> I've been wondering about something – zip files already contain CRC based
> checksums for each the stored file. What benefit is there in storing a
> RECORD file which basically duplicates this functionality?
>

AFAIU, there's no good way to do post-install hash verification like
`debsums` and `rpm -V` with zip CRCs (though it's probably possible if
there's a structured log of installed packages).


>
>
> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
> signing keys are valid for which package? Are pre-shared keys then still
> necessary, or do we then rely on a PKI where one compromised CA cert can
> then forge any other cert?
>
> https://theupdateframework.github.io/
>
>
>
> On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith <njs at pobox.com>ared wrote:
>
> Even if no maintenance were required, it's still a feature that promises
> to provide security but doesn't. This kind of feature has negative value.
>
> I'd also suggest adding a small note to the PEP documenting that the
> signing feature didn't work out, and maybe linking to Donald's package
> signing blog post. I know updating PEPs isn't the most common thing, but
> it's the main documentation of the wheel format and it'll save confusion
> later.
>
> On Mar 22, 2018 10:57 AM, "Wes Turner" <wes.turner at gmail.com> wrote:
>
> What maintenance is required?
>
> Here's a link to the previous discussion of this issue:
>
> "Remove or deprecate wheel-signing features"
> https://github.com/pypa/wheel/issues/196
>
> What has changed? There is still no method for specifying a keyring;
> whereas with GPG, all keys in the ring are trusted.
>
> On Thursday, March 22, 2018, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 22 March 2018 at 22:35, <alex.gronholm at nextday.fi> wrote:
>
> I am not changing the format of RECORD, I'm simply removing the
> cryptographic signing and verifying functionality, just the way you
> described. Hash checking will stay. As we agreed earlier, those
> features could be deprecated or removed from the PEP entirely.
>
>
> Cool, that's what I thought you meant, but I figured I should double check
> since our discussion was a while ago now :)
>
> Cheers,
> Nick.
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180322/155f8ffe/attachment.html>


More information about the Distutils-SIG mailing list