このほど、GitHubがgemのパブリッシュを快適に行える独自のRubyGemsサーバの運営を開始した。自分のレポジトリーのルートにgemspecを置き、GitHubコンフィギュレーションのボックスをチェックするだけでgemがビルドされ、他の人たちにインストールしてもらえるようになる。他のユーザーのgemとの衝突を避けるため、ユーザーネームがプリフィックスとして使用され、[ユーザー名]-[プロジェクト名]の形式を取る。
しかし、今やRubyGemsのユーザーにとって、gemのソースはRubyForgeだけではない。追加のGitHub ソースのコンフィギュレーションが必要である。これは、それほど大きな障害ではないように見えるが、Magnus Holm氏がブログで指摘しているように(リンク)、厄介な側面がある。一番の問題となりそうなのは、自動依存管理である。RubyGems では依存関係が同じサーバ上にあるものと仮定しているため、相性が良くないのだ。さらに、GitHubの特定のgemの作者名を知っている必要がある。
より詳しく知るために、InfoQ はRubyGems の管理者であるEric Hodel 氏、GitHub のPJ Hyett 氏、およびRubyForge のTom Copeland 氏との対談を行った。
Eric Hodel氏はこの問題の詳細を次のように説明した。
最大の問題となりうるのが、ダッシュ(-)を含むgemです。悪意のあるユーザーがGitHubでnetというアカウントを作成し、RubyForge のnet-sshよりバージョンの高いパッケージであるsshをリリースすることができます。RubyGemsはGitHubのバージョンをインストールするでしょうが、これは望ましくありません。
残念ながら、一般的にはこれは特長として活用されているのです。gems.rubyonrails.org (および他の開発サイト)には、gems.rubyforge.orgと同じ名前のgemを改定したバージョンが掲載されています。名前は一致するものという共通認識があるため、RubyGemsは改定バージョンを取得するのです。
ソースの追加はインターネット上のあらゆるソフトウェアのインストール同様、自己責任である。
現在、このような問題に対する最良の手段はgemの作者が、自分のリリースするgemに署名を行うことです。これによって、gemユーザーは特定のgemについて信頼できるソースまで遡ることができるのです。信頼の輪を作り上げるのが簡単なことなのかどうか、今はわかりません。けれども、私はhoeにコードを追加し、rake generate_key を実行すると、自動的にリリースしたgemに署名を行うようにしました。(詳細はri Hoe参照) gemの署名と認証については、ri Gem::Securityに詳細な記述があります。
gemがRubyForgeとGitHubでリリースされているため、gemの作者に「brixen-mspecまたはrubyspec-mspecまたはmspecに依存しています」という宣言を可能にする交互依存に関する議論が行われています。John Barnette とYehuda Katz はこれの実装について関心を持っていたようでしたが、私の知る限り、まだ何の進展もありません。
今現在、GitHubのgemを得るためには、RubyGemsのソースにユーザー自身がgems.github.comを追加する必要がある。Ericによれば、「（GitHubをデフォルトのソースに追加することについて）完全に反対というわけではないけれど、交互依存がなければ、あまり有益だとは思わない」とのこと。
GitHub のPj Hyett氏もHodel氏の意見に同意している。
Ericの名前の重複についての懸念は、間違いなく私達にとっても悩みです。実際に、netというユーザーネームのユーザーがsshという名前のgemをビルドする、というケースが既に起こっていますからね。幸いなことに、そのユーザーは私達がその脆弱性に気づくように実演して見せてくれたのでした。もちろん、すべてのユーザーがそれほど親切というわけではないでしょうから、解決法を見つける必要があります。一番困るのは、提供しているサービスによって、私達が日常的に使用しているシステムが破綻することですから。
私達は元々、username/repo-nameという命名規則に従ってGitHubのgemをビルドしようとしていました。ですから、このような重複が問題となるはずではなかったのです。また、これによって私達のURL構造を模倣することができるという利点もありました。しかし、残念なことに、RubyGems のボックスでスラッシュは使えません。私達はユーザーがGitHubのgemをコードにパッチを適用せずとも使えるようにしたかったのです。
RubyForge のTom Copeland氏は、RubyForgeプロジェクト用にgemを自動パブリッシュすることを検討している。
たぶんプロジェクトのadminタブに何らかの追加を行って、ユーザーがsvn/git repoにあるgemspecを指定して私達はそれをビルドする、もしくはユーザーがrepoのルートを指定して、私達はそこにあるlibディレクトリを探し、プロジェクト名をgem名、svn repoの改定をgem番号とすることになるでしょう。（中略）そのような機能に需要はあるのでしょうか？
別の選択肢としては、「RubyForgeプロジェクトの作成」および「RubyForgeにパブリッシュする」という機能をGitHubに追加するという案もある。しかし、Copeland氏は「RubyForgeには現在、手動によるプロジェクト承認ステップがあります。私達は、GitHubからのプロジェクト作成リクエストをどのように自動承認し、設定すべきかを考えなくてはなりません」と指摘する。
Pj Hyett氏はこのアイデアについて、次のように述べています。
「RubyForgeにパブリッシュする」ボタンについて、強く反対するつもりはありません。ですが、正直に言えば、単に私達のシステムを彼らのサイトと連携させるだけの方が好ましいと思っています。GitHubでgemをビルドすることは、コードを向こうのレポジトリに転送するということでしかなく、我々のユーザが既にやっていることと変わらないのですから、これ以上考える必要はないのです。
とはいえ、gemのビルドに関してセキュリティや他のさまざまな理由によって、私達が対応することのない要求を含む固有の要求を行う人種というのは必ず現れるものです。ですから、私達は今でも、私達が提供している機能以上のことを望むのであれば、RubyForge を使用することを推奨しています。
要するに、関わっている人たちはたとえ実装や合意に時間が掛かろうとも、解決法を見出そうとしている。
gemをGitHubにパブリッシュすることは自動化できるが、Ryan Davis氏のHoe(リンク)を利用すれば、RubyForgeへのパブリッシュも自動化できる。これはRubyForgeにgemをリリースできるタスクなどを含むRakeおよびRubyGems向けの補助ツールである。Hoeを正しくセットアップすれば、rake release VERSION=x.y.z という簡単なコマンドひとつでリリース可能だ。 Hoe について詳しく知りたければ、Nuby on RailsのHoeに関するこのチュートリアル(リンク)をチェックすべきだろう。
あなたはGitHubでプロジェクトをホストしているだろうか？ そして、それをRubyForgeに転送しているだろうか？ また、それをどのように（ツール、スクリプト、タスクなど）活用しているだろうか？
原文はこちらです：