M. Takeyamaです。 On Tue, 15 Jun 2004 15:55:27 +0200 Takashi Iwai <tiwai@suse.de> wrote: [...]
パッケージのアップデートは、
・パッケージの修正 ・パッチ情報の作成 ・セキュリティ・チームによる修正の検証 ・QA チームによるパッチおよびアップデート情報の検証 ・実際にサーバに流す
という冗長なパスを通っているためです。 丁寧な説明ありがとうございます。
全てのセキュリティ対応がそうであると断言はしませんが KDE Project の関係者としてどうしてこんなに時間がかかっているのか理解できません。 (もっと早く対応できる能力はあるはずだと思ってしまいます。) ＃Waldo Bastian(元リリースコーディネータ, kdelibのメンテナ(多分,今も)) ＃Dirk Mueller(元リリースコーディネータ) ＃Stephan Kulow(現リリースコーディネー) ＃Adrian Schroeter(SUSE用KDE パッケージのメンテナ) http://www.kde.org/info/security/advisory-20040517-1.txt
Waldo や Coolo ができるのは上記２番目までです。 修正パッケージに時間がかかるのは、上記のパスの後半部分がボトルネックと なっているのです。 各パッケージ管理者からパッチが出るのは簡単ですが、その修正を実際に検証 する、というのは、責任が伴うので面倒なのですね。
このプロセスの遅さは、社内でも文句が出ていて、QA にもっとマンパワーを 回すことで今後は改善される予定なのですが…。 そうですか。 日本が特に厳しいというわけでは無いと思いますが、 コンピュータ・セキュリティ・インシデントの対応プロセスを明確化、 法制化(義務化)をいう動きがあります。 ベンダー(ディストロ)にとっては、対応力(セキュリティ)がいろいろな 意味で重要になってくるのではないでしょうか。
もっとも、一番の理由は人手不足だろうとも思うのですが。 約400人のエンジアがいても大変なんですね。
そんなにいませんよ :) SUSE 全社員が 400 人未満、実際に開発に携わっているのは半分もいないは ずです。 SUSEをNovellが買収したときのNovellのえらい人(会社の重役)の コメントにエンジニア数(=400 人)だったような気がします。 ＃セールストーク(Novellの重役) or 私の勘違いかもしれません。
----- M. Takayama