[Catalog-sig] RubyGems Threat Model and Requirements

[Giovanni Bajo]

Il giorno 12/feb/2013, alle ore 08:57, Nick Coghlan <ncoghlan at gmail.com> ha scritto:

> On Tue, Feb 12, 2013 at 10:39 AM, Donald von Stufft
> <donald.stufft at 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.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130212/c1c8c260/attachment.bin>