[Distutils] Removing wheel signing features from the wheel library

Justin Cappos jcappos at nyu.edu
Thu Mar 22 16:53:43 EDT 2018


You don't need a traditional CA for use with TUF or need to worry about a
single PKI.  TUF is built to be resilient to the compromise of single
servers / keys.

Typically you would ship the metadata about what keys to trust (TUF's "root
metadata") with the software installation tool.  This single set of
pre-shared metadata means you can securely obtain the rest of the
software.  (I'm happy to go into more detail, but wanted to avoid this
becoming a barrage of TUF details unless everyone is interested.)

If you don't want to ship the metadata with the tool, you can also have it
work in a trust-on-first-use model.  This is what Docker does in their
deployment of TUF.

On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> 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.
>
> 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.
>>>>>
>>>>> --
>>>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>>>
>>>>
>>>> _______________________________________________
>>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>>
>>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180322/1d2331d8/attachment-0001.html>


More information about the Distutils-SIG mailing list