卜部です。

Shugo Maeda さんは書きました:
> で、ここからが提案なのですが、ruby_1_8_6/ruby_1_8_7ブランチでは、適用後
> ただちにリリースを行う必要があるような重大な修正(たとえばセキュリティフィックス)
> 以外は行わないようにしてはどうでしょうか。
>
> これにより、
>
> * セキュリティフィックスをリリースする際のデグレードのリスクを減らすことができる。
> * ディストリビュータが脆弱性に対する修正点を確認しやすい。
> * メンテナの負担が減る。
>
> というメリットがあります。
>
> デメリットは、これまで行われていたようなバグ修正がruby_1_8_6やruby_1_8_7
> に適用されなくなることですが、リリースしなくても大多数の人はそれほど困らない
> ような修正なら1.8.8まで待ってねということでよいのではないでしょうか。
> それよりもセキュリティフィックスの際に混乱が起きないことの方が重要なように思います。
>   

んー、そうすると今度は何をもってセキュリティフィックスと呼ぶかという問題
になる気がします。

たとえば単にcoreを吐いて終了するだけのようなバグに対しての修正は、いまの
私達の基準ではセキュリティフィックスには含まれていませんが、本当はそうい
うのだって立派にDoS Attackで使えるわけです。かとおもえばたとえばCVE-2007
-5162などはべつにcoreを吐くことはありませんが、これはこれでMITM Attack可
能なのでセキュリティフィックスに含まれていますよね?

つまり今の私達のセキュリティフィックス基準というのは実はたいへんに偏って
いると思います。「セキュリティフィックスに限る」とかにしてしまうなら、い
まよりきちんと何をもってセキュリティ上の脅威と呼ぶか決めておかないと、な
んでもかんでもセキュリティフィックスだと叫び出す人が出てきたり、なにもか
もがセキュリティフィックスではないと叫び出す人が出てくるでしょう。

私は、今のなんとなくユルい運用も嫌いではありませんが、いまの運用が許され
ているのは、ひとえに「問題に対する修正は重要度に限らずやがてすべての枝に
入る」という前提があるからだと思っています。この前提なしでは、ある問題に
対する重要度の評価がいまほどダメな状態は危険だと思います。

> 別の案としては、セキュリティフィックスを出す際には、直前にリリースしたパッチレベル
> まで遡ってセキュリティフィックスだけ適用したものをリリースする、ということも考えられ
> ますが、バージョニングをどうするかが問題になりますし、私としては前者の案の方が
> シンプルでよいと思っています。
>   

これはバージョン番号が単調じゃなくなるのでなんか色々難しいことが起きそう
です。