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. A doc from last week is a hard sell. It makes sense that system package managers would not use TUF directly since those other projects are not written in Python. 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.
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
