<br><br>On Thursday, March 22, 2018,  <<a href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti:</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><br><br>On Thursday, March 22, 2018, Daniel Holth <<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>> wrote:<br><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">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.</div><br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></blockquote><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>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?</div><div><br></div><div><a href="https://theupdateframework.github.io/" target="_blank">https://theupdateframework.<wbr>github.io/</a></div><div> </div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>>ared wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 22, 2018 10:57 AM, "Wes Turner" <<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>> wrote:<br type="attribution"><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">What maintenance is required?<div><br></div><div>Here's a link to the previous discussion of this issue:</div><div><br></div><div>"Remove or deprecate wheel-signing features"</div><div><a href="https://github.com/pypa/wheel/issues/196" target="_blank">https://github.com/pypa/wheel/<wbr>issues/196</a></div><div><br></div><div>What has changed? There is still no method for specifying a keyring; whereas with GPG, all keys in the ring are trusted.<br><br>On Thursday, March 22, 2018, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 March 2018 at 22:35,  <span dir="ltr"><<a href="mailto:alex.gronholm@nextday.fi" target="_blank">alex.gronholm@nextday.fi</a>></span> wrote: <br><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><div>I am not changing the format of RECORD, I'm simply removing the<br></div></div>
cryptographic signing and verifying functionality, just the way you<br>
described. Hash checking will stay. As we agreed earlier, those<br>
features could be deprecated or removed from the PEP entirely.<br></blockquote><div><br></div></div>Cool, that's what I thought you meant, but I figured I should double check since our discussion was a while ago now :)<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br><pre>______________________________<wbr>_________________
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a>
</pre></div></div></blockquote></div></blockquote></div></div></blockquote></div></blockquote></blockquote></div></blockquote>