[Catalog-sig] RubyGems Threat Model and Requirements

[Daniel Holth]

On Tue, Feb 12, 2013 at 1:39 PM, Jesse Noller <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)> 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)>
> 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)>
> 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)
> 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)
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130212/dbc12da7/attachment.html>