On Thursday, March 22, 2018, Justin Cappos <jcap...@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.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
