[Catalog-sig] RubyGems Threat Model and Requirements

[Konstantin Andrianov]

On Feb 12, 2013, at 2:20 PM, holger krekel wrote:

> On Tue, Feb 12, 2013 at 12:44 -0500, Daniel Holth wrote:
>> On Tue, Feb 12, 2013 at 11:27 AM, Giovanni Bajo <rasky at develer.com> wrote:
>>>> 
>>>> 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.
> 
> For one, not all PHDs follow clean implementation and automated testing 
> principles.  Secondly, I appreciate Giovanni's input, work, and his offer
> to help with implementation.  Let's not be too quick to dismiss it.
> On a funny sidenote, he is the only one with a successfully openssl-verified 
> email in these security related email threads, just saying :)

I totally agree that PhD students can write messy code.   I've been working with Prof Cappos
to try to clean up the code, improve the testing, etc. in preparation for broader dissemination for
more than a year.   So, we've been spending a lot of time on improving TUF's code quality and 
robustness.  

Feel free to take a look and let us know what you think about our code...


Cheers,
Konstantin Andrianov