Square Hack Week project: secure updates for RubyGems
Jordi Massaguer Pla
jmassaguerpla at suse.de
Thu Oct 3 10:27:00 UTC 2013
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:
>> 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:
>> 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
> 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:
> Is this the direction you think we should go / are we going?
More information about the RubyGems-Developers