In message <454AA560.9090105 / moonwolf.com>
	on Fri, 3 Nov 2006 11:11:53 +0900,
	MoonWolf <moonwolf / moonwolf.com> wrote:
> >>     * パッチを当てたファイルは1.68.2.18になるが、CVSから取得できる
> >>       1.68.2.18とは実体が異なる(1.68.2.17の変更が含まれていない)ので
> >>       混乱の元である。
> > そういう意味では、CGI::REVISIONは当てにはならないということです。
> 
> 実体が違うのであれば、REVISIONを変える必要があるのでは?
現状の REVISION はCVSでファイルを管理している「記し」が残っているだけ
です。

> 1.68.2.17による処理の違いを説明するのに「1.68.2.17以降」という表現が
> できませんね。
できません。

要はCVSに管理されているものと違った内容になった時点で、意味がなくなる
わけなのです。様々なパッケージ・システムで独自に修正を行っている場合も 
REVISION に頼ることはできません。

これを解決するには、

1. 別にセキュリティ・パッチを表す定数を導入する。例えば、

	CVS::REVISION = '2006/11/2 10:10:10'

   といったものを導入する。

2. セキュリティや基本的な障害だけの修正しか加えない、リリース(今回であ
   れば Ruby 1.8.5)からブランチさせた修正リリース用のCVSブランチを使っ
   て管理する。

といった、ことが考えられます。

ブランチの寿命は次のリリースまでとなりますが、修正する内容を限定すれば、
それほど保守自体に手間はかからないでしょう。

> >>   * シェルが開放されていないサーバだと大変。
> > レンタルサーバ?  そういった場合は、そのサーバでシェルを使える管理者が
> > きちんと更新すべきではないのかしら?
> 
> 自分の借りているサーバでパッチがあたっているか自分で確認することが難しい
> ということです。
なるほど。

> いちいち管理者に問い合わせるか、CGI::REVISIONを表示させるCGIなどを作って
> 確認しなくてはいけません。
それにしても、先に書きましたようにRubyがパッケージ・システムで管理され
ている場合は、CGI::REVISIONで判断できない場合は残るので、それだけに頼
ることは結局できないと思います。

> > おそらく、今回のセキュリティの問題に直接関係のない、互換性を損なう恐れ
> > があるnkfに関する変更が1.68.2.17で行われているためでしょう。セキュリティ
> > 対応のパッチのためであれば、ちょうど1.68.2.17と1.68.2.18の差分でちょう
> > ど良いことになります。
> 
> 1.68.2.17による変更が行の追加、削除を伴わないシンプルなものであったから
> 良いものの、複雑な変更をまたいでいたらパッチとしてなりたたなかったという
> ことです。
今回は確かに幸運です。

現状の ruby_1_8 のブランチは、セキュリティなどの最低限の修正を加えるだ
けのものでは(外野な私から見てもそうでは)ありません。いわゆる stable バー
ジョンの「開発用ブランチ」としかなっていません。

で、ある以上、特定のセキュリティの問題に対するパッチを単純にCVSの特定
のレビジョンの差分で提供することは元々困難なわけです。このような状況で、
単なるCVSレポジトリの「記し」であるREVISIONに何かを求めても無駄です。

> 1.6.28.16に対するパッチのはずなのに、1.6.28.17に対するdiffというのは、
> パッチを当てる時に不安になりませんか?
と、いうわけで私は元々そこまで REVISION に重きを置いていませんし、それ
よりも変更された内容を見て判断します。CVSのレポジトリで差分を見ること
もできますし、特に不安には思いません。

-- 
神戸 隆博 / Takahiro Kambe