[Distutils] [tuf] PEP 458: Surviving a Compromise of PyPI: Round 1

[Donald Stufft]

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 time.
> 
> Justin
> 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:
> 
> http://www.python.org/dev/peps/pep-0458/
> 
> Whereas latest revisions to the PEP are here:
> 
> https://github.com/theupdateframework/pep-on-pypi-with-tuf
> 
> We welcome your feedback and suggestions.
> 
> Thanks,
> The PEP 458 team
> 
> 


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131121/1aae7a56/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131121/1aae7a56/attachment.sig>