A RubyGems + GitHub proposal
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
Comments are disabled