[Distutils] vetting, signing, verification of release files

[Justin Cappos]

Essentially, nothing changes from the user's standpoint or from the
standpoint of the package developer (except they sign their package).

The reason why we have multiple roles is to be robust against attacks in
case the main PyPI repo is hacked.

(Trishank can chime in with more complete / precise information once he's
back.)

Thanks,
Justin


On Wed, Jul 17, 2013 at 3:24 PM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
> On 17 Jul, 2013, at 19:17, Trishank Karthik Kuppusamy <
> tk47 at students.poly.edu> wrote:
> >
> > To very briefly summarize our status without going into tangential
> details:
> >
> > 1. We previously found and reported on this mailing list that if we
> naively assigned a key to every PyPI project, then the metadata would not
> scale. We would have security with little usability. This looks like an
> insoluble key management problem, but we think we have a pretty good
> solution.
> > 2. The solution is briefly this: we now propose just two targets roles
> for all PyPI files.
> > 2.1. The first role --- called the "unstable" targets role --- will have
> completely online keys (meaning that it can kept on the server for
> automated release purposes). The unstable role will sign for all PyPI files
> being added, updated or deleted without question. The metadata for this
> role will change all the time.
> > 2.2. The second role --- called the "stable" targets role --- will have
> completely offline keys (meaning that keys are kept as securely as possible
> and only used with manual human intervention). The stable role will sign
> for only the PyPI files which have vetted and deemed trustworthy. The
> metadata for this role is expected to change much less frequently than the
> unstable role.
> >
> > Okay, sounds too abstract to some. What does this mean in practice? We
> want to make key management simple. Preferably, as Nick Coghlan and others
> have proposed before, we would want PyPI to initially, at least, sign for
> all packages, because managing keys for every single project right off the
> bat is potentially painful. Therefore, with that view in mind --- which is
> to first accommodate PyPI signing for packages, and gradually allowing
> projects to sign for their own packages --- we then consider what our
> proposal above would do.
> >
> > Firstly, it would make key management so much simpler. There is a
> sufficient number of offline keys used to sign metadata for a valuable and
> trustworthy set of packages (done only every now and then), and an online
> key used to make continuous release of PyPI packages possible (done all the
> time).
> >
> > 1. Now suppose that the top-level targets role says: when you download a
> package, you must first always ask the stable role about it. If it has
> something to say about it, then use that information (and just ignore the
> unstable role). Otherwise, ask the unstable role about it.
> > 2. Fine, what about that? Now suppose that the both the stable and
> unstable roles have signed for some very popular package called FooBar 2.0.
> Suppose further that attackers have broken into the TUF-secured PyPI
> repository. Oh, they can't find the keys to the stable role, so they can't
> mess with the stable role metadata without getting caught, but since the
> unstable keys are online, they could make it sign for malicious versions of
> the FooBar 2.0 package.
> > 3. But no problem there! Since we have instructed that the stable role
> must always be consulted first, then valid metadata about the intended,
> trusted FooBar 2.0 package cannot be modified (not without getting all the
> human owners of the keys to collude). The unstable role may be tampered
> with to offer bogus metadata, but the security impact will be limited with
> *prior* metadata about packages in the way-harder-to-attack stable role.
>
> I'm trying to understand what this means for package maintainers. If I
> understand you correctly maintainers would upload packages just like they
> do now, and packages are then automaticly signed by the "unstable" role.
>  Then some manual process by the PyPI maintainers can sign a package with a
> stable row. Is that correct? If it is, how is this supposed to scale? The
> contents of PyPI is currently not vetted at all, and it seems to me that
> manually vetting uploads for even the most popular packages would be a
> significant amount of work that would have to be done by what's likely a
> small set of volunteers.
>
> Also, what are you supposed to do when FooBar 2.0 is signed by the stable
> role and FooBar 2.0.1 is only signed by the unstable role, and you try to
> fetch FooBar 2.0.* (that is, 2.0 or any 2.0.x point release)?
>
> Ronald
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130717/c2a101ac/attachment.html>