Sure. The "stable" key is kept offline (not on PyPI). It knows who the developers for projects are and delegates trust to them. So Django (for example), has its key signed by this offline key.
The "bleeding-edge" key is kept online on PyPI. It is used to sign project keys for projects newer than the last use of the stable key. If I register new project "mycoolnewpypiproject" and choose to sign my packages then it delegates trust to me. Importantly, if the stable and bleeding-edge roles trust the same project name with different keys, the stable role's key is used. A malicious attacker that can hack PyPI can get access to the bleeding-edge key and also some other items that say how timely the data is and similar things. They could say that "mycoolnewpypiproject" is actually signed by a different key than mine because they possess the bleeding-edge role. However, they can't (convincingly) say that Django is signed by a different key because the stable key already has this role listed. Sorry for any confusion about this. We will provide a bunch of other information soon (should we do this as a PEP?) along with example metadata and working code. We definitely appreciate any feedback. Thanks, Justin On Wed, Jul 17, 2013 at 9:54 PM, Donald Stufft <don...@stufft.io> wrote: > > On Jul 17, 2013, at 9:52 PM, Justin Cappos <jcap...@poly.edu> wrote: > > > If there is not a compromise of PyPI, then all updates happen > essentially instantly. > > > > Developers that do not sign packages and so PyPI signs them, may have > their newest packages remain unavailable for a period of up to 3 months *if > there is a compromise of PyPI*. > > Can you go into details about how things will graduate from unstable to > stable instantly in a way that a compromise of PyPI doesn't also allow that? > > > > > Thanks, > > Justin > > > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig