[Catalog-sig] RubyGems Threat Model and Requirements

[Daniel Holth]

On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com> wrote:

> Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <ncoghlan at gmail.com>
> ha scritto:
>
> > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <rasky at develer.com>
> wrote:
> >> Hello Nick,
> >>
> >> I've added the initial Requirements and Thread Model section to my
> document. I've also added a section "Future scenarios" at the end of the
> document.
> >>
> >> I hope they complete what you were feeling was missing from the
> proposal.
> >
> > Thanks, that helps me a lot in understanding the overall goals of your
> > approach - in particular, it more clearly puts several things out of
> > scope :)
> >
> > Your Task #6/#7 (related to PyPI generating the trust file, and pip
> > verifying it) are the ones where I think the input of the TUF team
> > will be most valuable, as well as potentially the folks responding to
> > the rubygems.org attack.
>
> My undestanding is that #6/#7 are not currently covered by TUF. So yes, I
> would surely value their input to review my design, evolve it together or
> scratch it and come up with something new.
>
> Sorry for the repetition, but I also volunteer for implementation. I don't
> mind if someone else does it (or a subset of it, or we split, etc.), but I
> think it is important to say that this is not a theoretical proposal that
> someone else will have to tackle, but I'm happy to submit patches (all of
> them, in the worst case) to the respective maintainers and rework them
> until they are acceptable.
>
> > The rubygems.org will also be looking at server side incident response
> > - I suspect a lot of that side of things will end up running through
> > the PSF infrastructure team moreso than catalog-sig (although it may
> > end up here if it involves PyPI code changes.
>
>
> While I do have some ideas, I don't think I'm fully qualified for that
> side of things. Primarily, my proposal helps by not forcing PyPI to handle
> an online "master" signing key with all the required efforts (migration,
> rotation, mirroring, threat responses, mitigations, etc.). If you read it,
> you had seen that PyPI is only required to validate signature (like pip),
> not sign anything.
>

The alternative is to just use a system implemented by several PhD
[candidates?] in 2010 based on years of update system experience, before
pypi security was cool. A doc from last week is a hard sell.

It makes sense that system package managers would not use TUF directly
since those other projects are not written in Python.

At first I didn't like the idea of pypi running a CA or an associated CA
but I think it is a fantastic idea. There would be no key revocation or
third-party keyservers, just up-to-date positive assertions (including
necessary keying material) about whether a key was allowed to sign a
particular package. The threshold signatures (n of m signatures required,
both can be 1) feature is pretty mind-blowing as well.

We should trust our servers. We already do for https, the keys are online,
and it is a good thing. When pypi is hacked Martin will tell us and we can
roll back to some earlier verifiable state.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130212/80b79bc9/attachment-0001.html>