[Distutils] [tuf] Re: vetting, signing, verification of release files
jcappos at poly.edu
Thu Jul 18 04:06:04 CEST 2013
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.
On Wed, Jul 17, 2013 at 9:54 PM, Donald Stufft <donald at stufft.io> wrote:
> On Jul 17, 2013, at 9:52 PM, Justin Cappos <jcappos at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG