On Tue, Feb 12, 2013 at 1:39 PM, Jesse Noller <[email protected]> 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 > > > > <[email protected](mailto: > [email protected]) (mailto:[email protected])> wrote: > > > > > Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan < > [email protected] (mailto:[email protected]) (mailto:[email protected])> > ha scritto: > > > > > > > > > > > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo < > [email protected] (mailto:[email protected]) (mailto:[email protected])> > 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.
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
