卜部です。 Yukihiro Matsumoto さんは書きました: > * セーフレベル4はほとんど使われていない 結局ここが一番意識が違うところです。ほとんど使われてないとか言うにはあま りに使われています。 http://www.google.com/codesearch?q=%22%24SAFE+%3D+4%22+lang%3Aruby > * 使われているtDiaryでも「第三者からの任意のコードを実行する」 > というわけではない(まだHikiは未確認だけど、おそらく状況は > 類似) > ホスティングしてれば第三者な可能性があります。 また、間違いなく任意のコードではあります。 > ということを考えると、影響度は限定的だと考えます。 ということを考えれば影響度は限定的ではありません。 > まず、重要なのは > > * 1.8からセーフレベル4は削らない(削れない) > * 現在のセーフレベル4には(残念ながら)穴がある > * 開発を行わなければ穴はふさがれない > * 我々からの情報に頼らなくても穴を発見することは(実は)比較的 > 容易 > 確認したいのですがまつもとさんの中では開発と保守ってのは渾然一体なのですね? 俺(や、おそらく多くの職業プログラマはそうだと思いますが)はその二つは一応 線を引いて考えているので。 > ということです。このことから、1.8におけるセーフレベル4の穴を > 塞いで安全性を確立するためには、なんらかの改善を行う必要があ > ります。そのための作業の場所ですが、trunkや別バージョンで作業 > してもセーフレベルの本質が変わるわけではないので、その作業に > 関する情報そのものが1.8に対する0-dayアタックの引き金になる可 > 能性を否定できません。 > trunkでセーフレベルを考え直すとか言ってたのはもっとがらっと変えるんだと 思ってたんですが、セーフレベルの本質に踏み込んだ改善はなされないつもりな んですか。だとしたらあんまり意味ないなあ。 > 結局、ありえる選択肢は、セーフレベル4の危険性をどれだけと見 > 積もるかによって応じて > > 危険性を重視するケース(セーフレベル4は要らない派) > > * 使うなと厳命する。使っている人には「もうすぐ消えるから使わ > ないように書き換えろ」と脅す > * もっと過激に1.8からも削っちゃう > > - デメリット: tDiaryやHikiの開発者にとっては青天の霹靂。迷惑 > この上ない。 > - デメリット: 今ある機能を削るのは1.8のメンテポリシーにも反 > する。 > なぜ、俺の提案した「trunkからは削る/1.8.7までは残す」ってのは選択肢にす ら登ってないんですか? > 危険性をそれなりに重視するケース(セーフレベル4は残す派) > > * 開発者をつのって非公開で開発。ある程度完成度が高まったら一 > 気にコミット。 > > - デメリット: 非公開での開発がうまくいったためしがない > - デメリット: こちらかは0-dayアタックの情報をもらす心配はな > いが、自力で穴を発見する攻撃に対しては無力 > > あんまり使ってないから危険はそんなに気にしないケース > > * とにかくセーフレベル4をもうちょっとマシになるように > (ruby-devで)開発を継続する > > - デメリット: セーフレベル4の脆弱性情報が開発過程で公開され > ることになる > > くらいじゃないかと。私は最後の「公開で開発」派です。その背景 > は、上で述べたように > > * あまり使われていないので深刻度は低い > * 非公開での開発は独り善がりになりがちでむしろトラブルを呼ぶ > > というものです。ただ、ドキュメントで公式に「セーフレベル4の > 完成度は低く、信頼するのはいかがなものか」ということは明記し > た方がよいと思います。さっき確認したらFlanagan本にはそう書い > てありました。さすがDavid。 > まず、あまり使われてないってのは事実と反するので、全部公開して保守するの だけは絶対反対です。そこは引けません。 新規開発部分に関してはばっさり削っていちから作り直すのだと思っていました から、現在の実装とは異なる仕組み(たとえばtryrubyのようなもっとマシなサン ドボックスを提供するとか)の造り込みは別に公開でやってもいいと思うわけで すが、まつもとさんにその気がなくて、ちょっとセーフレベル4を弄ってお茶を 濁す程度の話なら、確かに公開するのが危険なのは頷けます。 したがってあんまりやる気がないなら全部非公開の案が一番マシだと思わざるを 得ません。