Square Hack Week project: secure updates for RubyGems
jcappos at poly.edu
Thu Oct 3 14:45:37 UTC 2013
Revocation is a big issue, as is appropriately separating trust. For
example, who do I trust to know what key corresponds to a project? I
think that RubyGems will do this.
Furthermore, I assume the repo would keep that online to sign new projects
as they are registered. If so, then if the repo is compromised, can I
just say that some attacker controlled key is responsible for signing for
any project? That would seem to make the impact of a compromise of the
repo be that they can hack all users of RubyGEMS even if the devels are
secure (a bad outcome!).
We're working with the Python folks to try to address this issue (and a
bunch of others). Specifically, we are working on a PEP that has a layout
/ use that will make it so that:
1) PyPI can immediately create accounts for new projects
2) even if an attacker compromises the repo and all keys on PyPI are
stolen, very few projects / users will be at risk
We could help to create a similar configuration / protections for RubyGems
as well. However, to make this work RubyGems will need to have richer
mechanisms than SUSE, RedHat, Debian, etc. use --- for instance, a way of
performing selective trust delegation.
The situation with RubyGems is more complex than for Linux package managers
because you don't trust your Gems devels and your users shouldn't trust the
RubyGems repo more than they have to.)
We are interested in working with you guys to plan a setup that is very
secure and has minimal impact on usability for users, developers, and repo
On Thu, Oct 3, 2013 at 6:39 AM, Jordi Massaguer Pla
<jmassaguerpla at suse.de>wrote:
> 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:
> >>> --
> >>> 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:
> >> 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:
> 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
> RubyGems-Developers mailing list
> RubyGems-Developers at rubyforge.org
More information about the RubyGems-Developers