<div><div>TUF, Warehouse, Pip, PyPA, ld-signatures, ed</div><div><br></div><div>"PEP 480 -- Surviving a Compromise of PyPI"</div><div><a href="https://www.python.org/dev/peps/pep-0458/">https://www.python.org/dev/peps/pep-0458/</a></div><div><br></div><div>"PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model"</div><div><a href="https://www.python.org/dev/peps/pep-0480/">https://www.python.org/dev/peps/pep-0480/</a></div><div><br></div><div><br></div><div><br></div><div>I need to spend time reviewing these PEPs. Backseat driving here; sorry:</div><div><br></div><div>Are there pypa/warehouse github issues for implementing the TUF trust root support in warehouse; and client support in pip (or a module that pip and other tools can use)?</div><div><br></div><div>Warehouse is already a SPOF.</div><div>That's a hefty responsibility that contributions should support.</div><div><br></div><div>Would [offline] package mirrors and the CDN still work for/with TUF keys?</div><div><br></div><div><br></div><div>ld-signatures has some normative language that could be useful.</div><div><br></div><div>ld-signatures uses URIs for signature suites (a canonicalization algorithm, a message digest algorithm, and a signature algorithm) and JSONLD. That should be pretty future proof in regards to the NIST post-quantum algorithms call that's under review at this time.</div><div><br></div><div>Blockcerts builds upon ld-signatures.</div><div><br></div><div>There's a compact form of JSONLD.</div><div>JSON[LD] can also be serialized as BSON (and RDFHDT).</div><div><br></div><div>"Linked Data Signatures 1.0" (draft)</div><div><a href="https://w3c-dvcg.github.io/ld-signatures/">https://w3c-dvcg.github.io/ld-signatures/</a></div><div><br></div><div>"Ed25519 Signature 2018" (draft)</div><div><a href="https://w3c-dvcg.github.io/lds-ed25519-2018/">https://w3c-dvcg.github.io/lds-ed25519-2018/</a></div><div>- canonicalizationAlgorithm: <a href="https://w3id.org/security#URDNA2015">https://w3id.org/security#URDNA2015</a></div><div>- digestAlgorithm: <a href="http://w3id.org/digests#sha512">http://w3id.org/digests#sha512</a></div><div>- signatureAlgorithm: <a href="http://w3id.org/security#ed25519">http://w3id.org/security#ed25519</a></div><div><br></div><div><br></div><div><a href="https://theupdateframework.github.io/">https://theupdateframework.github.io/</a><br></div><div><br></div><div><a href="https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification">https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification</a><br></div><div><br></div></div><br>On Thursday, March 22, 2018, Trishank Kuppusamy <<a href="mailto:trishank.kuppusamy@datadoghq.com">trishank.kuppusamy@datadoghq.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Wes,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br><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.<br></div></span><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><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></blockquote><div><br></div><div>Yes, you are right, the hashes need to be signed: otherwise you have integrity, but no authenticity.</div><div><br></div><div>We wrote PEPs <a href="https://www.python.org/dev/peps/pep-0458/" target="_blank">458</a> and <a href="https://www.python.org/dev/peps/pep-0480/" target="_blank">480</a> to discuss how TUF might be deployed on PyPI / Warehouse. The PEPs go into details about public key distribution. The TLDR is that is that clients (i.e., pip) need to be shipped with one self-signed root metadata file, and the rest of the PKI is bootstrapped from there. PyPI would act as an authority that distributes, revokes, and replaces public keys for packages.</div><div><br></div><div>More details on security vs usability also available in our <a href="https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/kuppusamy" target="_blank">Diplomat</a> paper.</div><div><br></div><div>If the community is interested, we'd love to discuss how we could help make this happen.</div><div><br></div><div>Thanks,</div><div>Trishank</div><div> </div></div></div></div>
</blockquote>