[ruby-core:49123] Re: [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.

So sorry for the continual delay. I'm setting this up right now but it appears that I (evanphx on github) don't have access to push to ruby/ruby. When I am added, I can update the repo immediately.  

--  
Evan Phoenix // [e-mail]


On Monday, November 5, 2012 at 11:45 AM, shyouhei (Shyouhei Urabe) wrote:

>  
> Issue #7085 has been updated by shyouhei (Shyouhei Urabe).
>  
>  
> It's now r37483. As another (or two) manual sync might happen you should find the latest repo-dump by the mtime field from:
>  
> ftp://ftp.ruby-lang.org/pub/incoming/
> ----------------------------------------
> Bug #7085: Subversion → GitHub gateway stops.
> https://bugs.ruby-lang.org/issues/7085#change-32457
>  
> Author: shyouhei (Shyouhei Urabe)
> Status: Assigned
> Priority: Immediate
> Assignee: ephoenix (Evan Phoenix)
> Category: Project
> Target version: 2.0.0
> ruby -v: not version dependent
>  
>  
> Abstract: Sorry for your inconvenience. Due to my resigning job
> at netlab.jp (http://netlab.jp), the Subversion to GitHub gateway stops now. The
> gateway was located there, maintained by me.
>  
> Biggest problem to reboot the gateway is its ssh private keys. it
> first ssh into the canonical svn server to pull the repo, then ssh
> into github to push it. Both ssh sessions need private keys and
> as the gateway runs totally automatic using cron, those keys are
> not passphrased.
>  
> Ruby's canonical repo has once been cracked. GitHub also had
> vulnerability before. Leaking these keys is a serious threat
> against our project. A malicious codes can be injected by using
> (either of) them.
>  
> So sorry, I don't want to put these keys on any VPS, IaaS, or
> colocations or anything like that. Doing so is in fact easy, and
> makes the gateway working again, but will introduce a huge
> security threat.
>  
> In order to properly fix this sitution, a RELIABLE place is
> mandatory, where no access is possible from the internet, yet the
> gateway itself can connect to ruby-lang.org (http://ruby-lang.org) and github.com (http://github.com).
> Normal company intranets behind NATs should suffice, like
> netlab.jp (http://netlab.jp) was, Though I doubt a "normal" company intranet will not
> welcome a black box like the gateway.
>  
> =========
>  
> Githubゲートウエイは卜部離職に伴い停止しております。現在のところ復
> 旧の見込みはございません。このようなアナウンスが事後になってしまい
> ましたことを深くお詫び申し上げます。根回しが足りてなくてごめんなさ
> い。
>  
> そもそもgithubへのゲートウエイは何らかのプロジェクトで開発されたも
> のではなく卜部が少しずつ暇を見つけてはメンテナンスしていたもので、
> その実態はNaCl東京支社の卜部席に設置してあった卜部私物計算機の中で
> 動いていました。離職に際しこの計算機は停止の上引き払いました。その
> ためサービスも巻き添えで停止したという形です。
>  
> 復旧に際して問題となるのはssh鍵です。仕組み上、ゲートウエイマシン
> はrubyのsvnサーバにsshしてデータを取得した後、次にはgithubにsshし
> てデータを更新する必要があり、それをcronで回す関係上、どちらで使う
> 秘密鍵も、ゲートウエイマシン上に、パスフレーズなしで存在している必
> 要があります。
>  
> Rubyのレポジトリにはクラックされた実績があります。githubにも脆弱性
> を突かれた実績があります。したがって、これらのパスフレーズのない
> ssh鍵が流出するのはかなり危険です。どちらの鍵が流出しても、Rubyの
> ソースコードに悪意ある改変を加えることが可能になります。私としては
> この鍵を自分の管理下にない計算機に設置したくありません。どこかの
> VPSなどを借りてスクリプトを動かせば、数分から数時間程度でゲートウ
> エイを移築できることは確認済みですが、その確認の際にも確認にはssh
> agent forwardingを用いました。
>  
> こういった理由により今すぐにgithubとの同期を復旧するのはなかなかに
> 困難です。いや、正確に言うのであれば、べつに技術的な困難はないのだ
> が、それをやるとセキュリティ上の懸念がある。少なくとも外部インター
> ネット側からのアクセスができない(が、こちらからはruby-lang.org (http://ruby-lang.org)と
> github.com (http://github.com)へのコネクションが張れる)ネットワークで、ある程度信頼で
> きるホストしか設置されていない場所、に相当する場所を探す必要がある
> という認識でおります。べつに普通の企業の社内ネットワークで構わない
> と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
>  
>  
> --  
> http://bugs.ruby-lang.org/
>  
>