Thank you Shyouhei Urabe,

Wouldn't be possible setup the bridge on same subversion server so it
doesn't require ssh keys to push?

The idea is: subversion repository is local, so is git repository.

We expose git repo too as read-only and we can ask github to mirror it as
github.com/ruby/ruby

That way we don't need ssh keys and basic gateway can run secure.

Who provides ruby svn?

Sorry for top posting. Sent from mobile.
On Sep 29, 2012 9:40 AM, "shyouhei (Shyouhei Urabe)" <shyouhei / ruby-lang.org>
wrote:

>
> Issue #7085 has been reported by shyouhei (Shyouhei Urabe).
>
> ----------------------------------------
> Bug #7085: Subversion → GitHub gateway stops.
> https://bugs.ruby-lang.org/issues/7085
>
> Author: shyouhei (Shyouhei Urabe)
> Status: Open
> Priority: Immediate
> Assignee:
> Category: Project
> Target version:
> ruby -v: not version dependent
>
>
> Abstract: Sorry  for your inconvenience.  Due to  my resigning job
> at  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  and  github.com.
> Normal  company   intranets  behind  NATs   should  suffice,  like
> 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と
> github.comへのコネクションが張れる)ネットワークで、ある程度信頼で
> きるホストしか設置されていない場所、に相当する場所を探す必要がある
> という認識でおります。べつに普通の企業の社内ネットワークで構わない
> と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
>
>
> --
> http://bugs.ruby-lang.org/
>
>