Bug #7085: Subversion → GitHub gateway stops.

• Status: Closed
• Assignee: ephoenix (Evan Phoenix)
• Target version: 2.0.0
• ruby -v: not version dependent

[shyouhei (Shyouhei Urabe)]

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へのコネクションが張れる)ネットワークで、ある程度信頼で
きるホストしか設置されていない場所、に相当する場所を探す必要がある
という認識でおります。べつに普通の企業の社内ネットワークで構わない
と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。

[shyouhei (Shyouhei Urabe)]

Memo: how to reboot the svn->git gateway

Prerequisite

1. You need be a ruby core committer; you'll have to access the ruby's
   canonical svn repo.

2. You need have a valid github account. Let me (shyouhei) know your
   github id, so that I can let you push things to github/ruby/ruby.

3. You need register non-passphrased SSH public keys to both the ruby
   repo and github. Securely manage the private counterpart of them.

4. You need have a reliable place as I wrote before.

5. You need a working server: inside that reliable place, with git(1),
   svn(1), as well as git-svn(1) properly set up.

Installation

1. Download following URL. This is the verbatim copy of the gateway
   script and its working directory, created right at the moment I
   shut my old gateway down.

   ftp://ftp.ruby-lang.org/pub/incoming/ruby-gateway.tar.xz.gpg

2. The file mentioned above is a GPG signed LZMA compressed TAR
   file. NEVER FORGET to make sure the thing you downloaded is
   properly signed by me.

3. Inside the tarball is a tiny script named github.sh. This is the
   gateway itself. Just invoke this script with no args and it will
   do everything needed -- works for me at least. You might have to
   modify the script to fit your directory placement though.

4. Once you are sure the script works well, setup a cron job to
   periodically run the script.

   • • • • • sh github.sh

   That's all. May the source be with you.

[luislavena (Luis Lavena)]

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)" [e-mail]
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/

[evanphx (Evan Phoenix)]

Hello shyouhei,

I would be happy to have RubyCentral run the gateway but I'd like to run it in colocation. I can guarantee security of the keys by using passphrases and ssh-agent. The machine in question will only run the gateway, nothing else, and be secured with separate ssh keys to secure access to it.

Would that be ok?

--
Evan Phoenix // [e-mail]

On Saturday, September 29, 2012 at 8:40 AM, shyouhei (Shyouhei Urabe) wrote:

Issue #7085 has been updated by shyouhei (Shyouhei Urabe).

Memo: how to reboot the svn->git gateway

Prerequisite

1. You need be a ruby core committer; you'll have to access the ruby's
   canonical svn repo.

2. You need have a valid github account. Let me (shyouhei) know your
   github id, so that I can let you push things to github/ruby/ruby.

3. You need register non-passphrased SSH public keys to both the ruby
   repo and github. Securely manage the private counterpart of them.

4. You need have a reliable place as I wrote before.

5. You need a working server: inside that reliable place, with git(1),
   svn(1), as well as git-svn(1) properly set up.

Installation

1. Download following URL. This is the verbatim copy of the gateway
   script and its working directory, created right at the moment I
   shut my old gateway down.

ftp://ftp.ruby-lang.org/pub/incoming/ruby-gateway.tar.xz.gpg

2. The file mentioned above is a GPG signed LZMA compressed TAR
   file. NEVER FORGET to make sure the thing you downloaded is
   properly signed by me.

3. Inside the tarball is a tiny script named github.sh (http://github.sh). This is the
   gateway itself. Just invoke this script with no args and it will
   do everything needed -- works for me at least. You might have to
   modify the script to fit your directory placement though.

4. Once you are sure the script works well, setup a cron job to
   periodically run the script.

• • • • • sh github.sh (http://github.sh)

That's all. May the source be with you.

Bug #7085: Subversion → GitHub gateway stops.
https://bugs.ruby-lang.org/issues/7085#change-29787

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 (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/

[shyouhei (Shyouhei Urabe)]

Hello.

On 09/30/2012 02:21 AM, Luis Lavena wrote:

Thank you Shyouhei Urabe,

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

Yes, SSH key business is not needed in this way.

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 http://github.com/ruby/ruby

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

Who provides ruby svn?

Also by netlab.jp ... So if they are OK to set up a git server, this is the ideal solution.

[shyouhei (Shyouhei Urabe)]

On 09/30/2012 02:33 AM, Evan Phoenix wrote:

Hello shyouhei,

I would be happy to have RubyCentral run the gateway but I'd like to run it in colocation. I can guarantee security of the keys by using passphrases and ssh-agent. The machine in question will only run the gateway, nothing else, and be secured with separate ssh keys to secure access to it.

Would that be ok?

Thank you. Is it possible for cron to use a forwarded SSH agent? I have no idea how.

[evanphx (Evan Phoenix)]

Yes, it is possible. If you're comfortable with this, I can set it up as soon as I have the gateway code.

• Evan // via iPhone

On Sep 29, 2012, at 6:27 PM, Urabe Shyouhei [e-mail] wrote:

On 09/30/2012 02:33 AM, Evan Phoenix wrote:

Hello shyouhei,

I would be happy to have RubyCentral run the gateway but I'd like to run it in colocation. I can guarantee security of the keys by using passphrases and ssh-agent. The machine in question will only run the gateway, nothing else, and be secured with separate ssh keys to secure access to it.

Would that be ok?

Thank you. Is it possible for cron to use a forwarded SSH agent? I have no idea how.

[shyouhei (Shyouhei Urabe)]

Hi, I guess you use a fixed SSH_AUTH_SOCK ? Then it's OK as long as you carefully
restrict the socket's permission. Anyone can read form the socket can fake you.
Anyway that's a normal security (not colo-specific). So go ahead, with care.

On 09/30/2012 04:05 PM, Evan Phoenix wrote:

Yes, it is possible. If you're comfortable with this, I can set it up as soon as I have the gateway code.

• Evan // via iPhone

On Sep 29, 2012, at 6:27 PM, Urabe Shyouhei [e-mail] wrote:

On 09/30/2012 02:33 AM, Evan Phoenix wrote:

Hello shyouhei,

I would be happy to have RubyCentral run the gateway but I'd like to run it in colocation. I can guarantee security of the keys by using passphrases and ssh-agent. The machine in question will only run the gateway, nothing else, and be secured with separate ssh keys to secure access to it.

Would that be ok?

Thank you. Is it possible for cron to use a forwarded SSH agent? I have no idea how.

[shyouhei (Shyouhei Urabe)]

FYI, to follow up latest security fixes, I triggered the script manually. github.com/ruby/ruby
is now synchronized against revision r37165 and the working copy is updated as:

ftp://ftp.ruby-lang.org/pub/incoming/ruby-gateway.r37165.tar.xz.gpg

[jonforums (Jon Forums)]

Thanks shyouhei for syncing the latest security fixes to the GH mirror.

What's the timeline for bringing the mirror back to life?

While I'm curious as to the new implementation (Evan's colo, single svn/git server, ??) I really just would like to see the mirror chugging along again.

[shyouhei (Shyouhei Urabe)]

I think it's Evan's move now.

[evanphx (Evan Phoenix)]

Sorry for the delay. I'll set this up this weekend.

--
Evan Phoenix // [e-mail]

On Monday, October 15, 2012 at 8:44 PM, shyouhei (Shyouhei Urabe) wrote:

Issue #7085 has been updated by shyouhei (Shyouhei Urabe).

I think it's Evan's move now.

Bug #7085: Subversion → GitHub gateway stops.
https://bugs.ruby-lang.org/issues/7085#change-30819

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 (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/

[luislavena (Luis Lavena)]

2012/10/19 Evan Phoenix [e-mail]:

Sorry for the delay. I'll set this up this weekend.

Hello Evan, did you had luck setting this up?

Is there a way I can help you out?

Thank you.

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[luislavena (Luis Lavena)]

2012/10/19 Evan Phoenix [e-mail]:

Sorry for the delay. I'll set this up this weekend.

Hello Evan,

Please apologize for constantly nagging you, but have any progress on
this? May I be of any assistance?

Thank you in advance.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[mame (Yusuke Endoh)]

I'm also expecting a revival of the github mirror :-)

--
Yusuke Endoh [e-mail]

[shyouhei (Shyouhei Urabe)]

I heard that they tagged 2.0.0's preview. Should I re-sync that by hand or wait for Evan to set up his environment?

[matz (Yukihiro Matsumoto)]

I vote for time-to-time manual sync until automatic sync is set up.

Matz.

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to ephoenix (Evan Phoenix)
• Target version set to 2.0.0

Evan Phoenix, ping?

--
Yusuke Endoh [e-mail]

[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/

[evanphx (Evan Phoenix)]

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/

[shyouhei (Shyouhei Urabe)]

Ya, added. Please try!

On 11/08/2012 03:24 PM, Evan Phoenix wrote:

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/

[evanphx (Evan Phoenix)]

It's working!

The mirror is back up, being sync'd every 5 minutes now.

Sorry again for the delay.

For those curious: The mirror is running on it's own VM and for security reasons is running not inside a cron task but instead inside a screen session. This allows me to keep the passphrases for the keys safe at the risk of having to hand restart it should the VM be reboot (something that is quite unlikely).

I'm going to be adding some monitors for the VM so we'll know if it has has been lost power for some reason, but if we notice that the mirror seems to not be updating, just ping me and I'll check on it.

--
Evan Phoenix // [e-mail]

On Thursday, November 8, 2012 at 5:01 PM, Urabe Shyouhei wrote:

Ya, added. Please try!

[jonforums (Jon Forums)]

http://i.imgur.com/HqMc5.jpg

[zzak (zzak _)]

Thank you Evan!

On Thu, Nov 8, 2012 at 10:14 PM, Evan Phoenix [e-mail] wrote:

It's working!

The mirror is back up, being sync'd every 5 minutes now.

Sorry again for the delay.

For those curious: The mirror is running on it's own VM and for security
reasons is running not inside a cron task but instead inside a screen
session. This allows me to keep the passphrases for the keys safe at the
risk of having to hand restart it should the VM be reboot (something that is
quite unlikely).

I'm going to be adding some monitors for the VM so we'll know if it has has
been lost power for some reason, but if we notice that the mirror seems to
not be updating, just ping me and I'll check on it.

--
Evan Phoenix // [e-mail]

On Thursday, November 8, 2012 at 5:01 PM, Urabe Shyouhei wrote:

Ya, added. Please try!

[shyouhei (Shyouhei Urabe)]

Sweet!

Also please close this ticket once you are sure.

On 11/08/2012 07:14 PM, Evan Phoenix wrote:

It's working!

The mirror is back up, being sync'd every 5 minutes now.

Sorry again for the delay.

For those curious: The mirror is running on it's own VM and for security reasons is running not inside a cron task but instead inside a screen session. This allows me to keep the passphrases for the keys safe at the risk of having to hand restart it should the VM be reboot (something that is quite unlikely).

I'm going to be adding some monitors for the VM so we'll know if it has has been lost power for some reason, but if we notice that the mirror seems to not be updating, just ping me and I'll check on it.

--
Evan Phoenix // [e-mail]

On Thursday, November 8, 2012 at 5:01 PM, Urabe Shyouhei wrote:

Ya, added. Please try!

[ko1 (Koichi Sasada)]

+1

(2012/11/09 12:14), Evan Phoenix wrote:

It's working!

The mirror is back up, being sync'd every 5 minutes now.

Sorry again for the delay.

For those curious: The mirror is running on it's own VM and for security
reasons is running not inside a cron task but instead inside a screen
session. This allows me to keep the passphrases for the keys safe at the
risk of having to hand restart it should the VM be reboot (something
that is quite unlikely).

I'm going to be adding some monitors for the VM so we'll know if it has
has been lost power for some reason, but if we notice that the mirror
seems to not be updating, just ping me and I'll check on it.

--
Evan Phoenix // [e-mail]

On Thursday, November 8, 2012 at 5:01 PM, Urabe Shyouhei wrote:

Ya, added. Please try!

--
// SASADA Koichi at atdot dot net

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed

Thanks for evan and shyouhei, it now works!