[Distutils] [tuf] PEP 458: Surviving a Compromise of PyPI: Round 1
jcappos at nyu.edu
Fri Nov 22 04:39:52 CET 2013
Okay, no worries. We just wanted to let everyone know where things are at.
On Thu, Nov 21, 2013 at 10:06 PM, Donald Stufft <donald at stufft.io> wrote:
> Right now Warehouse is primarily focused on feature parity, and I haven’t
> had time
> to re-read the PEP to see what it looks like at this time :(
> On Nov 21, 2013, at 2:56 PM, Justin Cappos <jcappos at nyu.edu> wrote:
> I wanted to let you guys know that the RubyGEMS guys are doing a
> hack-a-thon this week to integrate TUF into gems. It sounds like there
> will be some press coverage of this effort and TUF in general. Our media
> department is likely to make a big deal out of this so it may get blown up
> beyond just the tech media.
> Is there something we can do to help to move integration along with
> Warehouse? For example, we have just published some developer tools that
> should integrate smoothly into Warehouse. Would you like us to submit a
> pull request with proposed changes?
> We'd love to be able to announce protecting both languages at the same
> P.S. No worries if there are other priorities right now. We're content
> to help with integration on whatever timeframe you prefer.
> On Sat, Nov 16, 2013 at 11:22 PM, Trishank Karthik Kuppusamy <
> tk47 at students.poly.edu> wrote:
>> Hello everyone,
>> Donald, Justin and I have co-authored a PEP that recommends a
>> comprehensive security solution to allow PyPI to secure its users
>> against a wide array of compromises.
>> The gist of the PEP is that the changes to PyPI are essentially
>> invisible to users and developers unless an attack is underway.
>> The key design ideas are as follows:
>> * The main PyPI server will continue running as it is now, exposing
>> HTTPS and legacy XML-RPC operations.
>> * The next-generation PyPI server (Warehouse) will be exposing new API
>> as well as TUF metadata to clients.
>> * Developers do not have to opt-in to secure their projects with their
>> own TUF metadata. In that case, PyPI will sign these "unclaimed"
>> projects on their behalf. However, unclaimed projects will not be secure
>> against a PyPI compromise.
>> * To protect against a PyPI compromise, developers may choose to
>> register their public keys with Warehouse and upload their own signed
>> TUF metadata about their projects.
>> * Therefore, developers do not have to concern themselves with key
>> management in case they leave their projects as "unclaimed". When they
>> do claim their projects, they simply have to register their keys once
>> with Warehouse. After that, they may delegate signing for distributions
>> as they wish without depending on Warehouse.
>> * Clients will be instructed to first search for a project in the more
>> secure claimed metadata (protected by offline keys) before looking for
>> it in the less secure unclaimed metadata (protected by online keys).
>> * Whether or not a project is claimed or unclaimed, all projects will be
>> available through continuous delivery.
>> * Consistent snapshots allow clients and mirrors to safely read metadata
>> and data despite the addition of new files to PyPI.
>> * It is efficient to securely install or update a project despite
>> hundreds of thousands of files.
>> The official PEP is here:
>> Whereas latest revisions to the PEP are here:
>> We welcome your feedback and suggestions.
>> The PEP 458 team
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG