[Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519

Wes Turner wes.turner at gmail.com
Thu Mar 22 17:52:43 EDT 2018

TUF, Warehouse, Pip, PyPA, ld-signatures, ed

"PEP 480 -- Surviving a Compromise of PyPI"

"PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model"

I need to spend time reviewing these PEPs. Backseat driving here; sorry:

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)?

Warehouse is already a SPOF.
That's a hefty responsibility that contributions should support.

Would [offline] package mirrors and the CDN still work for/with TUF keys?

ld-signatures has some normative language that could be useful.

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.

Blockcerts builds upon ld-signatures.

There's a compact form of JSONLD.
JSON[LD] can also be serialized as BSON (and RDFHDT).

"Linked Data Signatures 1.0" (draft)

"Ed25519 Signature 2018" (draft)
- canonicalizationAlgorithm: https://w3id.org/security#URDNA2015
- digestAlgorithm: http://w3id.org/digests#sha512
- signatureAlgorithm: http://w3id.org/security#ed25519



On Thursday, March 22, 2018, Trishank Kuppusamy <
trishank.kuppusamy at datadoghq.com> wrote:

> Hi Wes,
> On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner <wes.turner at gmail.com> wrote:
>> 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?
> Yes, you are right, the hashes need to be signed: otherwise you have
> integrity, but no authenticity.
> We wrote PEPs 458 <https://www.python.org/dev/peps/pep-0458/> and 480
> <https://www.python.org/dev/peps/pep-0480/> 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.
> More details on security vs usability also available in our Diplomat
> <https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/kuppusamy>
> paper.
> If the community is interested, we'd love to discuss how we could help
> make this happen.
> Thanks,
> Trishank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180322/deb1d01d/attachment-0001.html>

More information about the Distutils-SIG mailing list