[Catalog-sig] RubyGems Threat Model and Requirements

holger krekel holger at merlinux.eu
Tue Feb 12 20:20:34 CET 2013


On Tue, Feb 12, 2013 at 12:44 -0500, Daniel Holth wrote:
> On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com> wrote:
> > >
> > > 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.

For one, not all PHDs follow clean implementation and automated testing 
principles.  Secondly, I appreciate Giovanni's input, work, and his offer
to help with implementation.  Let's not be too quick to dismiss it.
On a funny sidenote, he is the only one with a successfully openssl-verified 
email in these security related email threads, just saying :)

best,
holger


More information about the Catalog-SIG mailing list