[Distutils] Removing wheel signing features from the wheel library

[Wes Turner]

On Thursday, March 22, 2018, Justin Cappos <jcappos at nyu.edu> wrote:

> 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.
>

[Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519
https://mail.python.org/pipermail/distutils-sig/2018-March/032081.html

I split the thread. Thanks for the explanation.


>
> 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/971c0759/attachment-0001.html>