Il giorno 12/feb/2013, alle ore 18:44, Daniel Holth <dho...@gmail.com> ha scritto:
> On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <ra...@develer.com> wrote: > Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <ncogh...@gmail.com> ha > scritto: > > > On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <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 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 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. Sarcasm is not appreciated, but I got your point (= PhDs rule, you poor guy suck). I think I've already elaborated on why TUF is just a subset of what we need for PyPI, so it's not useful to reiterate. I'm now looking forward to talk to Justin, when he is available. > At first I didn't like the idea of pypi running a CA or an associated CA but > I think it is a fantastic idea. There would be no key revocation or > third-party keyservers, just up-to-date positive assertions (including > necessary keying material) about whether a key was allowed to sign a > particular package. The threshold signatures (n of m signatures required, > both can be 1) feature is pretty mind-blowing as well. > We should trust our servers. We already do for https, the keys are online, > and it is a good thing. When pypi is hacked Martin will tell us and we can > roll back to some earlier verifiable state. All of the above benefits are present also with my design, that doesn't require an online signing key. *Especially* if you trust the server, those benefits are there (though not trusting the server is a basic part of the threat model of both TUF and my proposal). -- Giovanni Bajo :: ra...@develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
