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 <jcap...@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 > <t...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
