On Thursday, March 22, 2018, <alex.gronh...@nextday.fi> wrote: > to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti: > > > > 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. > > > 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 <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. > > _______________________________________________ > Distutils-SIG maillist - > Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
