On Tuesday, February 12, 2013 at 1:50 PM, Daniel Holth wrote:
> On Tue, Feb 12, 2013 at 1:39 PM, Jesse Noller <jnol...@gmail.com
> (mailto:jnol...@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 <ra...@develer.com
> > > > > (mailto:ra...@develer.com) (mailto:ra...@develer.com)
> > > > > (mailto:ra...@develer.com)> wrote:
> > > > > > Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan
> > > > > > <ncogh...@gmail.com (mailto:ncogh...@gmail.com)
> > > > > > (mailto:ncogh...@gmail.com) (mailto:ncogh...@gmail.com)> ha scritto:
> > > > > >
> > > > > > > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo
> > > > > > > <ra...@develer.com (mailto:ra...@develer.com)
> > > > > > > (mailto:ra...@develer.com) (mailto:ra...@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-develop...@rubyforge.org (mailto:rubygems-develop...@rubyforge.org)
for anyone who want to get some cross language collab going on :)
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
