Okay, no worries. We just wanted to let everyone know where things are at.
Justin On Thu, Nov 21, 2013 at 10:06 PM, Donald Stufft <don...@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 <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 > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig