Il giorno 12/feb/2013, alle ore 09:46, Giovanni Bajo <ra...@develer.com> ha scritto:
> Il giorno 12/feb/2013, alle ore 08:57, Nick Coghlan <ncogh...@gmail.com> ha > scritto: > >> On Tue, Feb 12, 2013 at 10:39 AM, Donald von Stufft >> <donald.stu...@gmail.com> wrote: >>> The folks on the ruby side of things who are dealing with a lot of >>> the same problems as Python/PyPI is have put together a document >>> containing a threat model and requirements of the system. While the >>> terminology is obviously ruby specific the concepts all apply to us. >>> >>> The document can be found here: http://goo.gl/ybFIO >>> >>> Further more since both languages are trying to solve the same problem >>> it would probably be a really good idea to join forces and hash out a system >>> and then diverge to actually implement it instead of both languages having >>> the same conversations in parallel. >> >> Thanks for posting this Donald - I was just coming to post it myself >> after it was initially published earlier today (Kurt grabbed me on IRC >> yesterday and suggested I have a look once he found out I had some >> involvement with PyPI security discussions). >> >> For Giovanni and others, this is the kind of high level "so what >> problem are we actually trying to solve?" thinking that I believe is >> needed before we rush off to devise tactical solutions to strategic >> problems (there *are* plenty of tactical problems that need to be >> addressed as well, we just need to make sure we distinguish between >> the two). > > > I think it all depends on how you want to approach the thing. A > multi-language threat model discussion between two different languages, with > different tools, and with very far-reaching scopes like "Provide a template > for unknown threat response", will probably take a good part of 2013. I would > respect a decision to embrace such a discussion, but I don't have resources > to dedicate to a such large-scale effort. > > On the contrary, my proposal attacks the most urgent issues, implements all > the low hanging fruits, and I could probably submit 100% of the required code > for review to the respective maintainers in 1 month from now, given an > overall approval of the structure (time required for review and rework > mandated by maintainers is beyond my reach of course). I am reasonably sure > that the design is sound; it might not be the *best* design in the world, and > any security design will always be subject to critique (as I've learnt over > the years), but it would bring us to a good point, very fast. In fact, I'm > sure we can improve it without affecting the implementation time by much, eg: > by having a discussion with the TUF guys. Looks like we'll have to wait a few > days for that, and that's OK. > > I will add an initial part in my document about design goals and threat > model. After that, I'm not willing to write a book about it, since it's > already more than enough to evaluate it and accept it or discard it (or > evolve it). I would respect if you prefer to have to solve the discussion in > a multiple-months discussion; it's just that I won't be part of that. I'm > sure there are enough competent people willing to help though. 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. -- 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
