Square Hack Week project: secure updates for RubyGems

Jordi Massaguer Pla jmassaguerpla at suse.de
Thu Oct 3 10:39:49 UTC 2013


On 10/03/2013 12:27 PM, Jordi Massaguer Pla wrote:
> On 10/03/2013 12:24 PM, Jordi Massaguer Pla wrote:
>> On 10/03/2013 05:26 AM, Tony Arcieri wrote:
>>> On Wed, Oct 2, 2013 at 6:22 PM, Benjamin Fleischer <bfleischer at gmail.com
>>> <mailto:bfleischer at gmail.com>> wrote:
>>>
>>>     Any update on this?
>>>
>>>
>>> Personally I've been thinking about this bundler proposal a lot and
>>> whether it and a few accompanying mechanisms can solve most of the
>>> problems in the TUF threat model:
>>>
>>> https://github.com/bundler/bundler-features/issues/27
>>>
>>> Specifically have a look at this response of mine, which transcends the
>>> goals of the actual Bundler issue, but I think covers most of the bases
>>> from an attack perspective:
>>>
>>> https://github.com/bundler/bundler-features/issues/27#issuecomment-25510553 
>>>
>>> -- 
>>> Tony Arcieri
>> Having a checksum of the gems in bundler Gemfile.lock file sounds very
>> good. This could help you knowing if a gem has changed.
>>
>> However, if the gem got compromised before you created your
>> Gemfile.lock, you won't know that you are using a bad gem.
>>
>> In order to solve the latter issue, I agree that having the checksum
>> signed will solve this issue, as long as the key used to signed it is
>> trustable.
>>
>> And there comes my question: how do we manage the trust on the keys?
>>
>> A similar problem has been fixed long time ago on linux distributions.
>> On a distribution like SUSE, SUSE employers will review the packages and
>> sign them with the SUSE key, which its public part is distributed in the
>> SUSE DVDs.
>>
>> However I don't think this model can be used in rubygems.org which
>> stores thousands of gems, and is mostly run on a community effort. Thus
>> I would go more on a trust model like gpg, I mean trusting individuals
>> in a chain of trust and having a revoke list.
>>
>> This is what debian does:
>>
>> http://www.debian.org/doc/manuals/developers-reference/new-maintainer.html
>>
>>
>> Is this the direction you think we should go / are we going?
>>

I am answering myself :) .

I've seen rubygems.org is going in this direction:

http://rubygems.rubyforge.org/rubygems-update/Gem/Security.html

though there is still some work in the TODO list, I think that is the
right direction. In my opinion, the most important missing piece is the
revokation part.

>> regards
>>
>> jordi
>>
> 
> _______________________________________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/rubygems
> RubyGems-Developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> 



More information about the RubyGems-Developers mailing list