[Catalog-sig] RubyGems Threat Model and Requirements

[Donald Stufft]

On Tuesday, February 12, 2013 at 1:50 PM, Daniel Holth wrote:
> On Tue, Feb 12, 2013 at 1:39 PM, Jesse Noller <jnoller at gmail.com (mailto:jnoller at gmail.com)> wrote:
> > 
> > 
> > On Tuesday, February 12, 2013 at 1:36 PM, Donald Stufft wrote:
> > 
> > > On Tuesday, February 12, 2013 at 1:22 PM, Jesse Noller wrote:
> > > >
> > > >
> > > > On Tuesday, February 12, 2013 at 12:44 PM, Daniel Holth wrote:
> > > >
> > > > > On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com (mailto:rasky at develer.com) (mailto:rasky at develer.com) (mailto:rasky at develer.com)> wrote:
> > > > > > Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <ncoghlan at gmail.com (mailto:ncoghlan at gmail.com) (mailto:ncoghlan at gmail.com) (mailto:ncoghlan at gmail.com)> ha scritto:
> > > > > >
> > > > > > > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <rasky at develer.com (mailto:rasky at develer.com) (mailto:rasky at develer.com) (mailto: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 (http://rubygems.org) (http://rubygems.org) (http://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 (http://rubygems.org) (http://rubygems.org) (http://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.
> > > >
> > > > A doc from last week trying to address and triage the same things that we're looking at that could help both communities, the same threat models, the same types of trust issues? Is it really that bad that we at least *try* to work with them and cross pollinate or are we really that awesome to completely ignore them and roll our own.
> > > The Ruby Doc and TUF are different pieces of the puzzle. The Ruby Doc was written independently of TUF and is mostly a requirements/spec sheet etc. Whereas TUF has that (in some forms) but it's also an implementation of something that satisified some of the requirements. I've shown the ruby guys TUF and they are looking into using that spec (reimplementing it in Ruby ofc).
> > >
> > > Trying to solve this problem without knowing what we are trying to solve is the wrong way of doing things. Also just accepting TUF was right is also the wrong way. Determining a proper set of requirements etc first, and then evaluating the options (of which TUF is one) is the way to go. The folks in #rubygems-trust have expressed interest in sharing information/ideas in the "plan/design" phases and then breaking off into our own respective communities for the actual implementation.
> > >
> > > More eyes are a good thing :)
> > Pretty much
> > 
> 
> It is very cool to work with the Ruby community. Cross-language-community collaboration is an excellent result.
Additionally their mailing for discussing this is rubygems-developers at rubyforge.org (mailto:rubygems-developers at rubyforge.org) for anyone who want to get some cross language collab going on :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130212/54790176/attachment-0001.html>