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 <bfleisc...@gmail.com >>> <mailto:bfleisc...@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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
