UmaShika さんのご指摘を受けて、アナウンスに更新履歴を追加し、さらに gpg 署名しました。
なお、ruby-list ML でも「脆弱性の原因を公開してほしい」旨の投稿がありましたが、いつ公開するかとかどこまで公開するかなどについて私の一存で決めるつもりもありませんし、どうぞ今しばらくお待ちくださいませ。
それはそれとして、皆さんの日記や blog 等で、広く対策を呼びかけてくださると幸いです。
[追記] 深刻さをもっとアピールすべきというのは、もちろんおっしゃるとおりなのですが、そのために具体的に何をすべきかアドバイスをいただけると幸いです。
[追記 2] ディストリビューションについては、私が知る範囲では hiki のパッケージがあるのは Momonga Linux と Debian だけと思います。Momonga はもちろん私が速攻でアップデートしています。Debian は、メンテナの方に (公開前にあらかじめ) メールで知らせました。packages.debian.org を検索した範囲では、testing は 0.6.3-1 ですが、unstable に 0.6.4-1 があるみたい。
原因を公開するかどうかはともかく、今回アナウンスされた脆弱性に対する攻撃の容易さを考えると、その深刻さはもっとアピールしたほうがいいんじゃないでしょうか。ruby-list で「Hiki を運用しているけど今すぐアップデートできない状況」なんてことが言われてますが、Web に公開されている Hiki なら、今回のケースでは論外でしょう。バッファオーバーランなんかの脆弱性はそれなりのスキルを持っている人が悪用するか、攻撃コードが出回るまではそれほど目立った被害は出ませんが、スキルとか攻撃コードとかいう問題じゃないですよね。
少なくとも、ruby-list での意見にたいして、その返事を日記でつぶやいてるのは積極的とはいえないような。
それは、ruby-list で議論すべき対象でないと考えていたからで、ここで「返事」をしたつもりではありません。
というわけで、今から「返事」を出しておきます。
アピールの方法ですが、Debian向けの場合などはBTSするなどすれば、アピールできるのではないでしょうか。ディストリごとに報告していくのは手間かもしれませんが、有効性はあると思います。
Debian では testing のパッケージは unstable からその urgency にあわせて「落ちてくる」ので、この場合 (urgency=high) は 2 日すると testing に来ます。（そもそも testing は security update の対象外なので、ある程度は仕方ない側面があるかも）
えーと、パッケージがあがっていればよい。という話ではなくて、
アピールの一つの方法としてBTSみたいな形で残すといことが有効なのではないかと思ったのでコメントさせていただきました。
メンテナ以外の人にも知ることができる方が有益だと思いましたので。closeされたバグがchangelogにのるので気に止めやすいですし。
通りすがりですが、たとえばBugtraq/Bugtraq-jp 等にSecurity Advisory として流すとか、そういう手段も
あるかと存じます。
既にやられているのであればすいません。