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 _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
