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.tur...@gmail.com> wrote: > > > On Thursday, March 22, 2018, Daniel Holth <dho...@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 <n...@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.tur...@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 <ncogh...@gmail.com> wrote: >>>> >>>>> On 22 March 2018 at 22:35, <alex.gronh...@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 | ncogh...@gmail.com | Brisbane, Australia >>>>> >>>> >>>> _______________________________________________ >>>> Distutils-SIG maillist - Distutils-SIG@python.org >>>> https://mail.python.org/mailman/listinfo/distutils-sig >>>> >>>> _______________________________________________ >>> Distutils-SIG maillist - Distutils-SIG@python.org >>> https://mail.python.org/mailman/listinfo/distutils-sig >>> >> > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig