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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-09-29 14:40
on 2012-09-29 14:41
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. 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.
----------------------------------------
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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で
きるホストしか設置されていない場所、に相当する場所を探す必要がある
という認識でおります。べつに普通の企業の社内ネットワークで構わない
と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-09-29 19:21
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>
on 2012-09-29 19:33
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 // evan@phx.io
on 2012-09-30 03:25
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.
on 2012-09-30 03:28
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.
on 2012-09-30 09:06
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 2012-09-30 14:48
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 2012-10-12 13:54
Issue #7085 has been updated by 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 ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-30431 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-10-15 23:13
Issue #7085 has been updated by 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. ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-30793 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-10-16 05:44
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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-10-20 05:00
Sorry for the delay. I'll set this up this weekend. -- Evan Phoenix // evan@phx.io
on 2012-10-23 21:48
2012/10/19 Evan Phoenix <evan@phx.io>:
> 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.
on 2012-10-28 16:36
2012/10/19 Evan Phoenix <evan@phx.io>: > 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.
on 2012-10-30 18:25
Issue #7085 has been updated by mame (Yusuke Endoh). I'm also expecting a revival of the github mirror :-) -- Yusuke Endoh <mame@tsg.ne.jp> ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-32036 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-11-01 20:48
Issue #7085 has been updated by 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? ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-32185 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-11-01 20:50
Issue #7085 has been updated by matz (Yukihiro Matsumoto). I vote for time-to-time manual sync until automatic sync is set up. Matz. ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-32186 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-11-05 15:04
Issue #7085 has been updated by 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 <mame@tsg.ne.jp> ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-32428 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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-11-05 20:46
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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-11-09 00:25
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 // evan@phx.io
on 2012-11-09 04:16
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 // evan@phx.io
on 2012-11-09 05:21
Issue #7085 has been updated by jonforums (Jon Forums). http://i.imgur.com/HqMc5.jpg ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-32670 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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
on 2012-12-10 09:08
Issue #7085 has been updated by naruse (Yui NARUSE). Status changed from Assigned to Closed Thanks for evan and shyouhei, it now works! ---------------------------------------- Bug #7085: Subversion → GitHub gateway stops. https://bugs.ruby-lang.org/issues/7085#change-34581 Author: shyouhei (Shyouhei Urabe) Status: Closed 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, 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へのコネクションが張れる)ネットワークで、ある程度信頼で きるホストしか設置されていない場所、に相当する場所を探す必要がある という認識でおります。べつに普通の企業の社内ネットワークで構わない と思いますが、そこに社業と関係ない計算機を設置する是非ですよね。
Enable email notification
Enable multi-page view
Please log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.