From: Shugo Maeda Date: 2008-07-16T09:53:25+09:00 Subject: [ruby-dev:35526] Re: ruby_1_8_6/ruby_1_8_7ブランチのメンテナンスポリシーについて 前田です。 2008/07/16 9:10 Tanaka Akira : > 拘りはないのかもしれませんが、セキュリティフィックス以外の修 > 正をどう扱うかを決めないと実際の運用はできませんよね。 そうですね。 > また、セキュリティフィックスが問題を導入することもあります。 > > たとえば、リストに出ている CVE-2008-2376 は Array#fill です。 > この修正は挙動を変えるということで、また別の修正が入っている > のですが、それはリストにはあげられていないようです。 > > 同様に、1.8.6p230 のセキュリティフィックスのひとつの alloca > のところの修正は潜在的に GC 問題があって、1.8 で修正しました > がまだ 1.8.6 には入っていません。 > > そういう問題はどう扱うんでしょうか。 セキュリティフィックスによって意図しない非互換性や新たな問題が 導入された場合、修正すべきだと思います。 その際の修正については、ruby-dev/ruby-coreなどで十分議論した 上で適用・リリースすれば大きな混乱は起きないものと考えています。 その過程で新しい脆弱性報告があるとやっかいですが、セキュリティ フィックス以外の修正をいったんリリースした後で、一定期間問題ない かどうか待った後にセキュリティフィックスをリリースする方がよいよう に思います。 > もし、前田さんの当初の案のように、セキュリティ問題以外は修正 > しないとすれば、これらは放っておくのでしょうか。 > > また、拘りはないとすれば、修正するのかもしれませんが、修正す > るとしたらどういう手順を踏むのでしょうか。 ruby-dev/ruby-coreなどで容易に合意を形成できるくらいに重大 な問題(たとえば、いつの間にか勝手にファイルを削除してしまうバグ とか)でないかぎり放置と考えていましたが、手順を工夫すれば適用 してもセキュリティフィックス時のリスクを抑えることができるかもしれ ませんね。 commitを今のように随時行う代りに、ある程度の期間まとめてから パッチを適用するようにして、適用後に一定のテスト期間を経た後に 速やかにリリースすることにするとか。 卜部さんの案にもリスクを低減させるために、チェンジセット32個ご とにリリースする、というのがありましたが、commitのタイミングが 今のように随時だとcommitからリリースまでの間隔がどれくらい 空くかわからないのが不安です。 > GC 問題はよくわからないときによくわからないことが起こるわけ > で、問題があることがわかってもどんな修正をする必要があるのか > 不明なわけですが、そうすると [ruby-dev:35413] の > 「この修正を適用しないなんてけしからん」という主張を行うこと > 自体が困難です。そうすると必然的にその主張をする人は少なくな > り、苦労して問題を同定して主張した挙げ句に 1.8 では修正され > てるけど文句を言う人は多くないので修正しない、と却下されるの > は幸せを追求する適切なやりかたなのでしょうか。 理想の姿かと言われれば、そうではないかもしれません。 -- Shugo Maeda