フリーソフトウェアの世界では、 内部での議論と一般向けのアナウンスの間に明確な違いはありません。 その一因としては、想定する読み手がはっきり定義できないことがあります。 ほぼすべての投稿が一般向けに公開されているとすれば、 プロジェクトの外部の人たちがその投稿をどう受け取るかなどコントロールできません。 プロジェクトの外部に公開するつもりなどまったくなかった投稿であっても、 たとえば slashdot.org へのタレコミなどの影響で何百万もの人に読まれることになるかもしれません。 オープンソースプロジェクトを運営していくにあたってこれは避けられないことです。 ただ、通常そのリスクはあまり大きくありません。 一般に、正しい方法で情報の報道価値を示しておきさえすれば プロジェクトの外部に伝えるべき情報はきちんと伝わるようになります。
重要なアナウンスの場合、その公開方法は 4 通りか 5 通りくらいになることもあります。 そして各方面へのアナウンスはほぼ同時に行わなければなりません。
プロジェクトのトップページは、おそらく最も多くの人たちが目にする場所でしょう。 重大なアナウンスに関しては、トップページにも掲載するようにしましょう。 ここに掲載するのは概要だけとし、詳細な情報を知りたい人のためには プレスリリース (以下で説明します) へのリンクを用意しておきます。
また、ウェブサイト上には「ニュース」や「プレスリリース」 と題した場所を設け、アナウンスの詳細はそこに書くようにします。 プレスリリースの目的のひとつは、 他のサイトからのリンクの際に使用する、正規の 「アナウンスオブジェクト」を用意することにあります。 したがって、プレスリリースは適切な構造にしておく必要があります。 プレスリリースごとに個別のウェブページを用意するにしても、 ひとつのblogの個別のエントリとするにしても、 あるいはその他の形式にするとしても、 他のサイトからリンクする際に 別のプレスリリースと区別できるようにしておかなければなりません。
そのプロジェクトが RSS フィードを提供しているのなら (「RSS フィード」 をご覧ください)、 そこにもアナウンスを含めなければなりません。 サイトの構築方法によっては、 プレスリリースを作成したら自動的にフィードも更新されるようになっているかもしれません。
新たなリリースが公開されたというアナウンスの場合は、 http://freecode.com/ 上のそのプロジェクトについてのエントリも更新しましょう (Freshmeat のエントリを作成する方法については 「広報」 をご覧ください)。 Freecode のエントリを更新すると、 Freecode の変更履歴を扱うメーリングリストにそのエントリの内容が投稿されます。 このメーリングリストに投稿されるのは Freecode の更新情報だけではありません。 それ以外にも、多数の人が注目しているポータルサイト (http://slashdot.org など) の更新情報も投稿されます。 Freecode は、これらのデータを RSS フィードでも提供しています。 つまり、あなたのプロジェクトの RSS フィードを購読していない人たちにも Freecode 経由で情報を伝えることができるのです。
あなたのプロジェクトのアナウンス用メーリングリストにメールを送信します。
アナウンス用メーリングリストの名前は "announce" とします。
つまり announce@yourprojectdomain.org
のようになるというわけです。
これは事実上の標準として使われている名前であり、
この名前のメーリングリストに流されるメールは
重要なアナウンスのみに限定しなければなりません。
流れるメールのほとんどは
そのソフトウェアの新たなリリースに関するものとなるでしょうが、
それ以外にも資金集めのお知らせやセキュリティ上の脆弱性の発見
(本章で後ほどとりあげる
「セキュリティ脆弱性の告知」 をご覧ください)
に関するメールも送信されます。
あるいは、プロジェクトが大きく方向転換する際のお知らせなども投稿されるでしょう。
announce メーリングリストの流量はあまり多くなく、
また重要な内容のみに使用するものです。
そのプロジェクトの各種メーリングリストの中でも
購読者の管理に最も力を入れる必要があります
(あまり乱用するのではなく、熟考してから投稿するようにしましょう)。
誰もが好き勝手にアナウンスを作成したり
スパムだらけになってしまうことを避けるため、
announce メーリングリストは
必ずモデレートしなければなりません。
これらの各所に出すアナウンスは、できるだけ同時になるようにしましょう。 メーリングリストに流されたアナウンスが プロジェクトのホームページやプレスリリースに反映されていなければ、 それを見た人は混乱してしまいます。 さまざまな変更 (メールの送信、ウェブページの編集など) を事前に準備しておいて同時に実行すると、 情報の一貫性が失われることが少なくなります。
それほど重要でもない出来事の場合は、 上であげた手法のうちいくつか (あるいはすべて) を省略してもかまいません。 出来事の重要性に応じて、それでもプロジェクトの外部には自然に伝わっていくでしょう。 たとえば「新しいリリースが公開されました」というのは重要な出来事ですが、 ただ単に「次のリリースの公開予定日が決まりました」 というのは、実際のリリースに比べてそれほど重要ではありません。 リリース予定日が決まったという程度の情報なら (アナウンス専用ではなく) 通常のメーリングリストに投稿し、 あとはウェブページ上のタイムラインを更新しておくくらいで十分でしょう。
しかし、あなたのプロジェクトに関心を持っている人たちは、 リリース予定日が決まったという話題をインターネット上の他の場所で持ち出すかもしれません。 メーリングリストに参加しているけれども ただ話を聞いているだけで自分は一切発言しないという人たちが、 必ずしも他の場所でも同じように黙っているとは限りません。 口コミの影響は侮れません。ちょっとしたアナウンスであっても、 それが正しい内容で周りに広まるよう心がける必要があります。 具体的に言うと、他の人に引用されることを想定した投稿では、 どの部分を引用してもらいたいのかを明確にし、 その部分は公式のプレスリリースと変わらないレベルで書くようにするということです。 たとえば次のようにします。
開発の最新状況をお知らせします。Scanley のバージョン 2.0 を、 2005 年 8 月中旬にリリース予定です。詳細な情報は http://www.scanley.org/status.html でもご覧いただけます。 このバージョンで追加される主要な機能は、正規表現による検索です。
その他の新機能は、 ... また、 次のようなバグの修正も含まれます ...
最初のパラグラフでは、ふたつの重要な情報 (リリース予定日と新機能) を簡潔に説明し、 さらに詳細な情報を知るための URL を示しています。 この部分だけしか読まなかったとしても、内容が伝わるようにしておきましょう。 メールの残りの部分は、他に伝わる際には無視される可能性があります。 もちろん、中にはメール全体へリンクする人もいるかもしれません。 しかし、ほとんどの人はメールの一部を引用するのみとなります。 そうである以上、一部を引用する人が引用しやすいようにすることを心がけましょう。 うまく引用してもらえば、情報を広く伝えることができます。
セキュリティ脆弱性の処理のしかたは、 他のバグ報告の場合とは異なります。 通常、フリーソフトウェアの世界では、 物事をオープンにして誰にでも見えるようにすることが当たり前のことです。 一般的なバグ報告の対応状況は、興味のある人なら誰にでも見えるようになっています。 いつバグが報告されたのか、どのような議論がなされたのか、 そして最終的にどのように修正されたのか。 これらはすべて、知りたければ誰でも知ることができるわけです。
セキュリティに関するバグの場合は、これとは異なります。 セキュリティに関するバグが原因でユーザーのデータが漏洩してしまう可能性もありますし、 場合によってはコンピュータを破壊してしまうことになるかもしれません。 このような問題をオープンな場で議論してしまうと、 問題があることを全世界に知らしめてしまうことになります。 当然その中には、そのバグを悪用しようという人たちもいることでしょう。 単に淡々とバグを修正してコミットしただけでも、バグの存在を世にさらしてしまうことになります (攻撃者の中には、公開されているプロジェクトのコミットログをチェックしている人もいます。 変更内容を調べれば、変更前のコードにセキュリティ上の問題があることがわかるでしょう)。 ほとんどのオープンソースプロジェクトでは、 この開放性と秘密主義の対立に折り合いをつけるために 同じような方針をとっています。その方針は、以下のようなものとなります。
修正が完了するまではバグのことを口外しない。 そして、バグがあったことをアナウンスすると同時に修正プログラムを公開する。
修正プログラムは、可能な限り迅速に提供する。 そのバグが外部からの報告で発覚したものである場合は特に急ぐ必要があります。 というのも、プロジェクトの外部の人間の中に少なくとも 1 人はその脆弱性を突く攻撃ができる人がいるということがはっきりしているからです。
実際のところ、この規則は標準化した手順としてまとめることができます。 これらの手順について、以下のセクションで解説します。
当然のことながら、各プロジェクトには セキュリティバグの報告を一般から受け付けるための窓口が必要です。 しかし、これは通常のバグ報告を受け付けるアドレスと一緒にはできません。 というのも、通常のバグは誰にでも見えるようになっているからです。 そこで、セキュリティ関連のバグ報告を受け取るためのメーリングリストを別途用意します。 このメーリングリストのアーカイブは一般に公開してはいけません。 また、参加資格は厳しく制限するべきです。そのプロジェクトに長くかかわっていて 信頼できる開発者たちのみをメンバーに加えるようにしましょう。 もし "信頼できる" の具体的な定義が必要な場合は、たとえば "コミット権を得てから 2 年以上経過している" などといった条件を使用するといいでしょう。 そうすれば、参加資格に関して "えこひいきしているのでは?" といった批判を避けることができます。 このメーリングリストに参加しているメンバーが、 セキュリティバグに対応するメンバーとなります。
セキュリティ関連のメーリングリストについては、 スパム対策やモデレートは行わないのが理想です。 というのも、重要な報告がスパム扱いされてしまうと困りますし、 たまたまその週末にすべてのモデレータがメールをチェックしなかったなどという理由で 重要な報告に気づくのが遅れるというのも困ります。 何らかのスパム対策ソフトウェアを使用するのなら、 可能な限り緩やか目の設定にしておきましょう。 重要な報告をフィルタリングしてしまうくらいなら、 多少のスパムが混ざってしまうほうがずっとましです。 作成したメーリングリストをうまく活用するためには、 そのアドレスを周知させる必要があります。 しかし、このメーリングリストはモデレートされておらず、 またスパム対策も甘いものです。したがって、 そのアドレスを宣伝するときには、アドレスを隠すために何らかの細工が必須となります。 詳細は 3章技術的な問題 の 「アーカイブでのメールアドレスの処理」 で説明します。 幸いにも、アドレスを読みにくいものになどしなくてもアドレスを隠すことは可能です。 http://subversion.tigris.org/security.html をご覧になったうえで、 そのページの HTML ソースを確認してみてください。
セキュリティメーリングリストに報告が来たら、次は何をすればいいのでしょう? まず最初にすべきことは、その問題の重大度 (severity) と緊急性 (urgency) を評価することです。
その脆弱性はどれくらい深刻なものでしょう? 悪意のある攻撃者が、 そのソフトウェアを使用しているコンピュータを乗っ取ってしまえるほどのものですか? それとも、ただ単に何らかのファイルのサイズが漏洩してしまうというだけのものですか?
その脆弱性を突く攻撃の難易度はどの程度ですか? スクリプトを使って誰でも攻撃できる程度のもの? あるいはその場の状況を熟知している人が 高度に頭を働かせても、ごくまれにしか成功しないもの?
誰が その問題を報告してきたのですか?
この問いへの答えによって脆弱性そのものの性質が変わるわけではありませんが、
他にどれくらいの人がその問題に気づいている可能性があるかを推測することができます。
もしそのプロジェクトの開発者自身から報告されたのなら、ちょっとだけ
(本当にちょっとだけ) 安心できます。
おそらく、その報告者は他人にその問題を漏らしていないでしょうから。
一方、もし anonymous14@globalhackerz.net
とかいうアドレスからのメールで報告を受けたのなら、
一刻も早く対応すべきでしょう。
あなたにその問題を報告してくれた人は、
あなた以外の人にもその情報を漏らしているかもしれません。
あるいは報告を受けたときには既にその脆弱性を突いた攻撃を始めているかもしれません。
ここで考えているのは、あくまでも 緊急 (urgent) と 超緊急 (extremely urgent) のどちらかというレベルの話であることに注意しましょう。 たとえ今回の報告が既知の信頼できるところからのものであったとしても、 それよりずっと前に他の人が同じ問題を発見しているが ただ報告していないだけなのかもしれません。 緊急性が低いといえるのは、 そのバグが本質的に深刻なセキュリティ問題を引き起こさないといえる場合のみです。
ところで、さきほどの "anonymous14@globalhackerz.net"
の例は、決して冗談で言ったわけではありません。
実際、このようにどこの誰だかわからないような相手からバグの報告を受けることもあり得ます。
彼らは自分の身元を明かすこともないでしょうし、
あなたの味方なのか敵なのかさえはっきりさせないでしょう。
でもそんなの関係ありません。あなたにセキュリティホールを教えてくれたということは、
向こうはあなたに対してひとつ貸しを作ったと考えているはずです。
それに対して、誠意を持って対応する必要があります。
まず報告してくれたことに対して感謝し、
修正版を公式リリースする予定日を彼らに伝えるようにします。
時には 報告者側から 日時を指定されることもあります。
つまり、「バグが修正されているかどうかにかかわらず、
○月○日になればこの問題を公表する」などどして暗黙の脅しをかけてくるようなものです。
これは単なる弱い物いじめに感じられるかもしれませんが、
おそらくその報告者が過去に経験したいやな思い出
(せっかくセキュリティ問題を報告してやったのに、
ソフトウェアの作者にまともに取り合ってもらえなかったなど)
に基づく先制攻撃と考えたほうが適切でしょう。
いずれにせよ、報告者をいちいち怒らせている余裕などありません。
結局のところ、もしそのバグが深刻なものなのだとしたら、
その報告者はユーザーに問題を引き起こさせる方法を知っているということになります。
彼の機嫌を損ねないよう丁重に扱いましょう。
そうすればきっと相手もこちらを尊重してくれることでしょう。
セキュリティバグの報告者としてほかによくあるのは、 セキュリティの専門家です。彼らはソフトウェアのコードを監査するのを仕事にしており、 ソフトウェアの脆弱性についての最新情報を追いかけています。 この手の人たちは、バグを報告する側だけでなくバグ報告を受け取る側としての経験も豊富です。 おそらくあなたのプロジェクト内のどのメンバーよりも経験を積んでいることでしょう。 また、彼らの特徴としては、期日を指定してその日までの対応を迫り、 期日がくればバグを一般に公表するというやり方があります。 交渉次第で期日を引き延ばすこともできるかもしれませんが、それは相手によります。 セキュリティの専門家たちにとっては、報告先にまともに取り合ってもらうための 唯一効果的な方法が期日を設定することなのです。 彼らが期日を指定してきたとしても、それを失礼だとは思わないようにしましょう。 それなりの理由があって続いている伝統なのですから。
重大度と緊急性を判定し終えたら、実際の作業に取り掛かり始めます。 修正をエレガントに行うか、それともとにかくすばやく修正するのかのトレードオフになることもあります。 このようなときのために、まず最初に緊急性を判定しておいたのです。 セキュリティに関する修正についての議論は、当然セキュリティメーリングリスト内でのみ行います。 また、問題の報告者がもし議論への参加を希望するなら、報告者もその議論に参加させましょう。 そして、技術的な理由でそれ以外の開発者が参加することもあるかもしれません。
修正内容をリポジトリにコミットしてはいけません。 一般に公開するまではパッチ形式で管理しておくようにします。 もし仮にそれをコミットしてしまったら、 たとえログメッセージを適当に取り繕っていたとしても 見る人が見ればその変更の意味するところを感づかれてしまいます。 どこの誰がどういう目的であなたのリポジトリをチェックしているかなんてわかりません。 コミットメールの送信をやめたとしても無意味です。 まず、コミットメールの送信が突然止まったという時点で 「なにか怪しい」と思われてしまうでしょう。 そしてコミットメールの有無にかかわらず、 その内容はリポジトリのデータとして残されているわけです。 修正の開発はすべてパッチ形式で行い、パッチは隔離された場所で管理します。 そのバグの対応をしている人たちだけが知っている個別のリポジトリなどがいいでしょう (Arch や SVK といった中央管理型ではないバージョン管理システムを使用しているなら、 完全にバージョン管理された環境で作業を進めることができます。 バグへの対応中は、外部からはリポジトリにアクセスできないようにしておけばいいのです)。
これまでに、セキュリティの問題の中で CAN 番号 や CVE 番号 といったものをみたことがある人がいるかもしれません。 たとえば "CAN-2004-0397" あるいは "CVE-2002-0092" といった形式のものです。
これらの番号は、どちらも同じ型の内容を表しています。これは http://cve.mitre.org/ で管理されている "Common Vulnerabilities and Exposures" リストのエントリを表します。このリストの目的は、 既知のセキュリティ問題についての共通の呼び名を提供することにあります。 そうすることで、個々の問題をはっきり区別できるようになります。 また、詳細な情報を探すための中央広場としての働きもあります。 "CAN" 番号と "CVE" 番号の唯一の違いは、 前者はまだ正式に認定される前の状態であるということです。 CVE Editorial Board によって認定されて公式リストに登場したものが後者となります。 しかし、どちらの情報も一般に公開されており、 認定の前後で番号自体は変わりません。 単に、番号の前の "CAN" が "CVE" に置き換わるだけのことです。
CAN/CVE のエントリ自体には、 バグの詳細な説明や対処方法などは含まれていません。 その代わりに、そのバグの概要説明と外部リソース (メーリングリストのアーカイブなど) へのリンクを用意し、 詳細な情報が知りたい人はそちらを参照すればいいようになっています。 http://cve.mitre.org/ の真の目的は、 きちんと整理整頓された場所を用意してすべての脆弱性に名前をつけ、 詳細なデータを得るための道筋を示すことです。たとえば、エントリの例として http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 を見てみましょう。その記述内容は非常に簡潔なものであり、 なにやら怪しげな略語をつけたリンクがあるだけです。 これらの略語の意味については http://cve.mitre.org/data/refs/refkey.html でご確認ください。
あなたが対応した脆弱性が CVE の条件を満たすようなら、CAN 番号の取得を検討するといいでしょう。 取得方法は、意図的に難しくしてあります。 基本的に、まずあなたが誰かの知り合いであるか、誰かの知り合いの知り合いである必要があります。 なんだかよくわからない言い方ですが、要はこういうことです。 脆弱性でもない内容や中身のないような報告に対応するのを避けるため、 CVE Editorial Board は既知の信頼できる情報源からの報告しか受け取らないのです。 したがって、脆弱性をリストに載せてもらうには、 あなたのプロジェクトと CVE Editorial Board の橋渡しをする仲介役が必要になるということです。 周囲の開発者に聞いてみましょう。その中に一人くらいは、 「以前に一度 CAN を取得したことがある」とか 「知り合いが CAN を取得していた」とかいう人がいるでしょう。 この方式の利点は、知り合いのつてをたどっていくうちに a) それは MITRE の言うところの脆弱性に該当しないから投稿する必要はない とか b) その脆弱性にはすでに CAN あるいは CVE 番号が割り当てられている といったことを教えてくれるかもしれないということです。 後者の可能性としては、そのバグが既に別のセキュリティメーリングリストで報告されているといったことがあります。 たとえば http://www.cert.org/、あるいは http://www.securityfocus.com/ の BugTraq メーリングリストなどがこれにあたります (もしあなたのプロジェクトに対して何も連絡がないまま後者の状態になっているのだとしたら、 自分たちのうかがい知れないところで何かが起こっているということを心配しなければなりません)。
どうせ CAN/CVE 番号を得るのなら、 普通はバグの調査段階のできるだけ早いうちに番号を取得したいものです。 そうすれば、その後のやりとりはその番号を使用して進めることができます。 CAN エントリは、一般に公開される日まで使用できません。 それまでは空のエントリが存在するだけ (場所を確保するだけ) であり、あなたがバグの存在と修正を公表するまで、 そこには何の情報も掲載されません。
CAN/CVE のプロセスについてのより詳細な情報は http://cve.mitre.org/cve/identifiers/candidates_explained.html で得られます。また CAN/CVE 番号を非常にうまく使っている オープンソースプロジェクトの例としては http://www.debian.org/security/cve-compatibility があります。
セキュリティ対策チーム (セキュリティメーリングリストのメンバー、 あるいはそのセキュリティ問題の対応担当者) が修正を完了したら、 次はそれをどのように公表するのかを判断する必要があります。
単に修正をリポジトリにコミットするとか全世界に公表するとかだと、 そのソフトウェアを使用している人たちは 事実上即時のアップグレードを迫られることになってしまいます。 さもないと、攻撃を受ける危険性が生じるわけですから。 したがって、ある種の重要なユーザー向けには 事前通知 をしておくほうが適切なこともあります。 いわゆるクライアント/サーバ型のソフトウェアなどでは特にこれが重要です。 有名なサーバが、一時的にでも攻撃の対象となってしまう可能性があるからです。 これらのサーバの管理者にとっては、アップグレードを行うためには 1 日から 2 日の時間が必要となるでしょう。 脆弱性が一般に公開される前にそのくらいの猶予があれば、 サーバの管理者はありがたいと思うことでしょう。
事前通知とは、単に一般公開前にそれらの管理者向けにメールを送信することを指します。 通知メールでは、脆弱性の内容とその対処方法を説明しておくようにします。 事前通知の送信先は、その情報を適切に扱ってくれると信頼できる相手に限定しなければなりません。 つまり、事前通知を受け取る資格があるのは、次のふたつの条件を満たす相手だけだということです。 まず、攻撃を受けると深刻な問題となるような巨大で重要なサーバを運営しているということ。 さらに、一般公開の前にその問題をペラペラしゃべってしまうような 口の軽い人ではないということ。
事前通知のメールは、それぞれの相手に個別に (一度に一通ずつ) 送信するようにします。 全員に一括送信などしては いけません。 そんなことをすれば、それを受け取った人たちに「私のほかにどんな相手に送っているのか」 を知られてしまいます。これが何を意味するのか。それを受け取った人は 「(私以外の) 他のメンバーのサーバにも同じセキュリティホールがある」 ということを知ってしまうことになります。 全員をブラインドカーボンコピー (BCC) で指定すればいいという問題でもありません。 受け取り先が使用しているスパムフィルタの設定によっては、BCC で送信されたメールをブロックしたり優先度を下げたりするようになっていることもあるからです (最近のスパムには、BCC を使用して送られてくるものが多いのです)。
事前通知メールの例を、ここに示します。
From: あなたの名前 To: admin@large-famous-server.com Reply-to: あなたの名前 (セキュリティメーリングリストのアドレスではありません) Subject: [機密] セキュリティ脆弱性の通知 このメールは、Scanley サーバにおけるセキュリティ警告に関する極秘の事前 通知です。 このメールの内容は、決して他人に転送しないでください。一般向けには 5 月 19 日に公表する予定です。それまではこの情報を口外しないようお願いいたし ます。 あなたにこのお知らせを送信した理由は、(おそらく) あなたが Scanley サー バをご利用いただいており、5 月 19 日にセキュリティホールを公表する前に パッチを適用したいであろうと考えられるからです。 参照: ===== CAN-2004-1771: Scanley stack overflow in queries 脆弱性: ======= サーバのロケールの設定が正しくない場合に、クライアントから不正な クエリを送信するとサーバ上で任意のコマンドを実行できるようになります。 重大度: ======= 非常に深刻。サーバ上で任意のコードの実行を許してしまいます。 回避方法: ========= scanley.conf で 'natural-language-processing' オプションを 'off' に設定することで、この脆弱性を回避可能です。 パッチ: ======= 以下のパッチは Scanley 3.0、3.1 および 3.2 に適用可能です。 新しい公開リリース (Scanley 3.2.1) が 5 月 19 日の直前に公開されます。 つまり、この脆弱性を公表するのと同時に公開するということです。以下の パッチを適用するか、あるいは新しいリリースが発表されるのをお待ちくだ さい。3.2 と 3.2.1 の違いは、以下のパッチのみです。 [...ここにパッチを示します...]
CAN 番号を取得している場合は、それを事前通知に含めるようにしましょう (先ほどの例で示したようにします)。まだ情報は公開されておらず MITRE のページには何も掲載されていませんが、それでも含める価値があります。 CAN 番号を示すことで、それを受け取った相手は「この通知で知ったバグと 後日正式に公開されるバグが確かに同じものである」ということを確認できます。 正式にバグが公開されたときに、余計な心配をせずにすむというわけです。 まさにこれこそが、CAN/CVE 番号の重要なところです。
セキュリティバグへの対応で最後に行うのが、 修正内容を一般に公開することです。 ひとつの包括的なアナウンスで、以下の内容を説明しなければなりません。 まずその問題の内容、そして CAN/CVE 番号を取得していればその番号、 当面の回避策と本質的な修正方法などを示します。 "修正" は、通常はそのソフトウェアの最新バージョンへのアップデートとなります。 しかし、ソースコード形式で実行されるソフトウェアなどでは、 パッチの適用をもって "修正" とすることもあります。 新しいリリースを作成した場合は、それが通常のリリースとは異なり セキュリティパッチの適用によるものであることを明示しておく必要があります。 そうしておけば、保守的な管理者であっても 副作用を気にせずにアップグレードできるようになります。 当然、今回のセキュリティ修正は将来のリリースにも含まれているでしょうから、 将来のアップグレードの際にも心配せずにすみます (リリース手続きの詳細については、 7章パッケージの作成、リリース、日々の開発 の 「セキュリティリリース」 で説明します)。
セキュリティ対応の修正で新バージョンをリリースするか否かにかかわらず、
通常の新バージョンのリリースと同程度の優先度でアナウンスを行うようにします。
つまり、そのプロジェクトの announce
メーリングリストにメールを送ったりプレスリリースを作成したり
Freecode のエントリを更新したりといったことです。
そのプロジェクトの評判を気にしてセキュリティバグの存在を甘く見るなんてことは論外ですが、
セキュリティに関するアナウンスの影響と実際の問題の重大度との兼ね合いには注意しましょう。
そのセキュリティホールが単に些細な情報が漏洩するというだけのものであって
コンピュータ全体がのっとられてしまうほどのものではないという場合は、
あまり大騒ぎしないほうがいいこともあります。場合によっては
announce メーリングリストへの投稿も控えるということもありえます。
ささいなことで毎回大騒ぎしていると、ユーザーはどう思うでしょう?
実際にはそれほどではないのに「このソフトウェアはあまり安全ではない」
と思われてしまうかもしれません。また、本当に深刻な問題が発生したときにそれをアナウンスしても、
「またいつものやつだろう」と無視されてしまう可能性もあります。
重要度の判断方法については、
http://cve.mitre.org/about/terminology.html
にすばらしい入門文書があるので、ぜひご覧ください。
セキュリティ問題の対処方法がよくわからない場合は、 経験がありそうな人を探して相談するようにしましょう。 脆弱性の評価やその処理の技術は、経験を積まないとなかなか得られないもので、 最初のうちは失敗することが多いものです。
セキュリティ脆弱性の扱いに関する Apache Software Foundation のガイドラインが http://www.apache.org/security/committers.html にあります。こちらも参照ください。この素晴らしいチェックリストを見れば、 自分がすべてを注意深く行っているかどうかを判断できます。