今までもたまにSecurity bug自体は直してたり (面倒であればバグを登録。最近もした) するんだけど、ほとんどの場合はリリース版になっていないベータとかTrunkのものでの話のバグを直すことばかりなので現在のプロセスに疎いことがあるんだけど (今の日本のオフィスで働いている人達に、いまってこういうプロセスになってたって知ってた？って聞いたら、「えっ？」って言わたのは内緒)、こんな感じで対応する。
- commit時のログには詳細を書かない。すっとぼけて大体こういうハンドリングに変えたとか。バグ番号だけのcommitの場合もあり
- テストケースでバレバレになってしまうものはリリース (Security Advisory) が出されてからテストケースをcommitする。それ以外の場合もあるけど、基本後でcommit。
- 考えられるシナリオをテンプレートに書く。Buffer Overrunとか。その内容次第で緊急リリースとかCVE番号含めて公開とか決定される。
というのもAndroidとかと違ってFirefoxは常に最新のソースツリーが公開されているのでコミットログのウォッチャーがセキュリティバグ修正の変更を見ることで簡単にセキュリティバグを見つけることができてしまう。そうなると悪意がある人達がZero-Dayなセキュリティインシデントものを作ることが可能になるので、それを対策するためにこういう風になってる。
またバグエントリもSecurity Permissionになるのでその権限を持ってる人しか見ることはできない。ただバグ番号はシーケンシャルに振られるので登録された日時の大体は予想が付くから、それとコミットログから、バグ報告から直すまでの時間のおおよそはわかるよね。
これがプロプライエタリ製品であればベンダがここのバージョンで直したとしか書かれないので、いつ報告を受けていつ直したかは、ベンダが公開するかどうかにかかってるから、直すまでにかかった時間はわからないよね。
Mozillaではこんな感じでオペレーションしてる。細かい話は、ここらのドキュメントを見るといいよ。
0 件のコメント:
コメントを投稿