M. Takayama です。 On Tue, 15 Jun 2004 12:07:03 +0200 Takashi Iwai wrote:

At Tue, 15 Jun 2004 13:15:19 +0900, takezou wrote:

...

SUSE 9.1のパッケージに問題があるとき --> 報告した。(まだ、Updateが出ていない。)

9.1 で解決していないのであれば、bug を reopen して、何らかのアップデー ト手段を講じるように文句を言ってください。別に躊躇する必要はありません。 はい。 アドバイスありがとうございます。 躊躇する理由は、 ・Bugzillaの使い方になれていないこと。(reopenしたことないです。) ・コミニュケーションが英語なので心理的な壁があります。 ＃KDEは、多少、得意分野なのでなんとかやっています。

もし、応答がないようであれば、severity を上げて再度文句を言う、と。 普段から不思議に思っていること。(前にも言ったことありますが...) セキュリティエラッタの出す時期(感覚的なもの) ---> 私の感覚的なものとは一致しません。 　　　他のバグなんかも一種独特の間(間隔)みたいなものがあるのかな？ 　　　と変に誤解しているのかもしれません。 ＃仕事がら毎日、オープンソースのセキュリティ情報をcheckしています。 ＃cvsの対応(cvs (SuSE-SA:2004:015))は、SUSEとしては異常に速かった ＃ような気がします。 ＃他のエラッタなんかは、「もっと速く対応しても良いのになー。」 ＃といつも思っています。

...

supplementary(SUSE 9.1)を使えば問題は解決する。 (でも、サポートはしない)

supplementary の場合は、実際サポート対象外ですし、そもそもパッケージを 自分でリビルドした場合には、ユーザの "at your own risk" になります。 それは、十分理解しているつもりです。 ＃この件は、「もっとうまい言い方は無かったかな」と反省しています。 ＃自分では、バグ報告のテストケースになっています。

ただ、KDE ProjectのMLには、SUSEパッケージ固有の問題を扱うメーリング リストはなかったような気がしますし、Bugzillaでもダメ。 supplementaryのようなものに対してのバグをfixしようとなると メンテナー個人宛(Adrian Schroeterさん)になってしまうという ことでしょうか？ Bugzillaのようにステータスがわかる、過去の履歴が検索できる というシステムの枠の中でどうにかできたら良いのではないか と思っています。 ＃”バグが放置されない”につながると思います。 ＜さらに発展して＞ たとえば、 ・SUSE 9.2 に○○機能をつけたい。(パッチレベルで) ・SUSE 9.2 に□□パッケージを追加してもらいたい という場合に、iwaiさん、mikeさんに個人的に相談しなくても勝手に出来る ような方法論があると良いと思います。 ＃iwaiさん、mikeさんに負荷がかからないと思いますので... ＃(場合によっては、影響あることは避けれないケースもあるかも。) ----- M. Takayama

M. Takeyama です。 On Tue, 15 Jun 2004 14:40:34 +0200 Takashi Iwai wrote:

At Tue, 15 Jun 2004 20:17:21 +0900, takezou wrote:

...

...

もし、応答がないようであれば、severity を上げて再度文句を言う、と。 普段から不思議に思っていること。(前にも言ったことありますが...) セキュリティエラッタの出す時期(感覚的なもの) ---> 私の感覚的なものとは一致しません。 　　　他のバグなんかも一種独特の間(間隔)みたいなものがあるのかな？ 　　　と変に誤解しているのかもしれません。

セキュリティ関連はかなり慎重にパッチを出しているようなので、そのせいで しょう。 他のディストリビューションと協調する必要がある、というのも理 由の一つだと思います。

反論するようですみません。 KDE Projectの内部事情を少しは知っているのでそれを例に取って、 少しコメントします。 最近発表があった、kdelibs の対応の件ですが、少なくとも、14/05/2004 にはデストロ(Vendor)にオープンになった情報の対応が、5/26にSUSEより kdelibs (SuSE-SA:2004:014)としてアナウンスされています。 パッチ作成は、Waldo Bastianさんがやったと思われますが 少なくとも KDEのコア開発者かつSUSEの関係者の４人が早い段階で 情報共有出来ています。 SUSEからセキュリティの正式アナウンスメントが出されるまで約２週間 かかっています。 全てのセキュリティ対応がそうであると断言はしませんが KDE Project の関係者としてどうしてこんなに時間がかかっているのか理解できません。 (もっと早く対応できる能力はあるはずだと思ってしまいます。) ＃Waldo Bastian(元リリースコーディネータ, kdelibのメンテナ(多分,今も)) ＃Dirk Mueller(元リリースコーディネータ) ＃Stephan Kulow(現リリースコーディネー) ＃Adrian Schroeter(SUSE用KDE パッケージのメンテナ) http://www.kde.org/info/security/advisory-20040517-1.txt

もっとも、一番の理由は人手不足だろうとも思うのですが。 約400人のエンジアがいても大変なんですね。 ご苦労さまです。

どうしてもすぐに直したい、ということであればそうなると思います。 Adrian Schroeterさんはまったく知らない人でもないので 今後はそうしたいと思います。 ＃(とりあえず、KDE 関係のことに限ってだけ。)

件の %run_permissions については、supplementary に関わらず、単に SUSE Linux のバージョンの問題ですし、ユーザがリビルドする状況だけで生じるの で、全パッケージを再構築する程深刻ではない、という判断でしょう。

bugzilla の報告自体が問題、というのではなく、supplementary にかける時 間は限られていて、プライオリティが低い、ということです。 (まともな)バグ報告自体はいつでも歓迎されるます。 了解です。 投稿(苦労して)して、５分後ぐらいにダメ出し、さすがにへこみましたね。 Stephan Kulow"coolo" さんの発言は、リリースコーディネータ的なんですよね。 (今までのやり取りでは) ＃個人的には、エンジニア的(論理的)に言ってくれれば理解するですけどね。

...

・SUSE 9.2 に○○機能をつけたい。(パッチレベルで) ・SUSE 9.2 に□□パッケージを追加してもらいたい という場合に、iwaiさん、mikeさんに個人的に相談しなくても勝手に出来る ような方法論があると良いと思います。

bugzilla に feature request として serverity を enhancement に設定して 報告してください。 了解です。ありがとうございます。

----- M. Takayama

M. Takeyamaです。 On Tue, 15 Jun 2004 15:55:27 +0200 Takashi Iwai 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