[Catalog-sig] RubyGems Threat Model and Requirements

[Giovanni Bajo]

Il giorno 12/feb/2013, alle ore 09:46, Giovanni Bajo <rasky at develer.com> ha scritto:

> 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.


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   ::  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/ae4493cc/attachment-0001.bin>