This post originated from an RSS feed registered with Ruby Buzz by Eric Hodel. Original Post: A RubyGems + GitHub proposal Feed Title: Segment7 Feed URL: http://blog.segment7.net/articles.rss Feed Description: Posts about and around Ruby, MetaRuby, ruby2c, ZenTest and work at The Robot Co-op. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Eric Hodel Latest Posts From Segment7

I know many people have added GitHub to their RubyGems sources list and find it sub-optimal. For example, Nokogiri is installed via gem install nokogiri from RubyForge and gem install tenderlove-nokogiri from GitHub. Furthermore, it’s possible to create a username/gem name combo on GitHub that overlaps a RubyForge name which could lead to pain and suffering for GitHub users.

I’ve come up with a potential solution to this problem:

• Add an alias name attribute to gem specifications that point to the “RubyForge name” for the gem
• Add an index to the gem server that maps alias names to “RubyForge names”
• Only signed gems with an alias name will be included in this index
• When RubyGems looks for a gem to install it considers aliased gems as exact matches for a name, provided they satisfy the user’s trust policy

Using this solution, a user could install a gem that has a dependency on nokogiri. If nokogiri is signed on GitHub and there’s a newer version on GitHub than on RubyForge, the GitHub version would be installed.

Here are some discussions points this solution presents:

• GitHub currently builds gems for authors, so it is impossible for these gems to be signed. GitHub would have to store the author’s private key for signing.
• By default RubyGems sets no security policy, so it doesn’t address the name overlap problem (this default could be changed)
• Furthermore, it would not prevent a trusted author from turning rogue
• Using a trust policy, a user can choose to pull gems from GitHub for specific authors by trusting the author’s public key (e.g. only install signed gems, only install trusted gems)
• There’s no infrastructure for easily trusting an author’s key (beyond gem cert)
• It doesn’t give GitHub a central authority for gems, but one could be built through a web of trust