Il giorno 12/feb/2013, alle ore 08:57, Nick Coghlan <[email protected]> ha scritto:
> On Tue, Feb 12, 2013 at 10:39 AM, Donald von Stufft > <[email protected]> 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. -- Giovanni Bajo :: [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
