Latest topics > Firefox 3でのアドオンの自動更新に関する仕様変更（セキュアじゃないアドオンは全部蹴られる件）
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Firefox 3でのアドオンの自動更新に関する仕様変更（セキュアじゃないアドオンは全部蹴られる件） - Sep 04, 2007
のりさんのところで報じられている、Firefox 3の仕様変更について、チェックインされたパッチを詳しく調べてみた。
今後拡張機能の自動更新では、以下の2つの段階でセキュアかどうかのチェックが入るようだ。
- install.rdfに書かれたupdateURL（更新情報を提供するRDFデータソースのURI）がhttpsで始まる、もしくは、updateURLで示された先のRDFデータソースであるXML文書が署名されていてinstall.rdfのupdateKeyに書かれた公開鍵で復号化できること。これが第一の条件。
- 更新情報を提供するRDFデータソースに書かれたupdateLink（新バージョンのXPIパッケージのダウンロード用URI）がhttpsで始まる、もしくは、updateHashでハッシュが示されていること。これが第二の条件。
この二つの条件が満たされてやっと、アドオンの自動更新が行われるという仕組みになっている。
よって、アドオン作者が取れる選択肢は以下の4つになる。
- install.rdfからupdateURLの記述を削除し、全ての更新をMozilla Add-ons経由で行うようにする。（Mozilla Add-ons経由の更新はhttpsなのでセキュア）
- 自前のサーバにSSL証明書を置いてhttpsで通信できるようにして、そこに更新情報提供用のRDFデータソースとXPIパッケージを置く。
- 更新情報提供用のRDFデータソースに署名して、さらに、その中にXPIパッケージのハッシュの情報も含めておく。
- 自動更新のための仕組みを提供しない。現実は非情である。
やる方として一番楽なのは1と4なんだけど、1には重大な問題がある。
- 公開申請に通ったアドオンは、ファイルを更新する度に審査があるので、審査待ちで長期間放置されると死亡。
- 公開申請してないアドオンは、ファイル更新の度の審査は不要だけど、ユーザから見えないから気付かれなくて使ってもらえなくて死亡。
というわけでもうちょっと素早く対応できる路線として2を検討してみようと思ったんだけど、仮にどうにかしてSSL証明書を手に入れたとしても、そもそもさくらのレンタルサーバじゃビジネス用プラン以外ではSSLは使えないんだってさ……
3はやりかた自体が分からない。XMLに署名するとかハッシュ値得るとか、僕の頭ではちんぷんかんぷんです。
ということでいずれにしても今の野良アドオン天国はオシマイだと言えよう。
追記。須藤さんにお願いして、cozmixngのサーバに置かせてもらえることになりました。よかったよかった。
Comments/Trackbacks
no title
自分は、基本は1. (Mozilla Add-ons) で、審査待ちの間は自サイトでupdate.rdfなしのXPIをダウンロード可能にし、急ぎの場合はブログとかで手動アップデートを呼びかける、という運用方法になりそうです。
大きな面倒小さな効果のような
私は「個人で」「install.rdfにupdateURLを記載している」アドオン作者でたぶんほとんど唯一今回特別な対応が必要なかったようです（1の「httpsで始まる」と2の「updateHashでハッシュが示されている」に該当）。方針は示されていたわけで、やっぱりそのときそのときに極力打てる手は打っておくべきだなぁ、と。
http://developer.mozilla.org/devnews/index.php/2007/05/30/add-on-updates/
ただ、XREAのサーバなら無料のスペースでもなんちゃってSSLが使えるので日本人は割となんとかなりそうな……
ただ自動更新使えないと更新が格段に面倒になりますよね。私なんか週平均一、二回は新しいバージョンを公開しているわけですから……
補足
仕様書を読むよりもパッチを読むところがPiroさんらしいなと思いましたがそれはともかく、
重箱の隅的なところもありますがちょっと補足させてください。
> 公開鍵で復号化できること。
アルゴリズムが同じだからいいじゃんという主張は分からなくもないですが、ここは用語的に「復号化」よりも「署名検証」のほうがよいかと思います。
あと、リンクにありますがXML Signatureは基本的には関係ないです。XML(RDF)に署名をしている程度のつながりしかなく、em:signatureはおそらく独自形式と思われます。ついでに
http://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSignature
のem:signatureの例は間違ってます。（bugzillaかどこかで指摘されてました）
ハッシュ値の計算にはFirefoxの拡張機能MDHashToolが使えます。
http://mdhashtool.mozdev.org/installation.html
最近更新されていないですが、0.4dpであれば対応バージョンを書き換えるだけで使えるはずです。
最後に、別のところの訳で出てきたのだと思いますがcryptographic keyを「暗号鍵」と訳すのは、encryption key（暗号化のための鍵）と混同されるのであまりよくないと思います。特にこの文脈では暗号化のために使われることはなく、もっぱら署名のために使われる鍵（＝署名鍵）ですので。
もともとの"cryptographic"は「暗号技術における」程度の意味で、つまり家のドアを開けるような鍵ではないですよーという前置きだと思います。日本語では略してしまってかまわないと思います。
用語説明がありましたのでもしよろしければどうぞ。
http://www.ipa.go.jp/security/rfc/RFC2828-03CJA.html#cryptographic%20key
[mozilla][extension][study]第八回Mozilla拡張機能勉強会
12月22日の第八回Mozilla拡張機能勉強会 Wikiに参加してきた。以下覚え書き。 mozilla Japanのエントランスに飾られていた、緑のgoo版Firefox？のクリスマスツリー。 電車の中で無線LANカードと名刺を忘れたことに気がつく。 参加予定者数が22名程と多いので、有線が確保で
TrackBack ping me at
の末尾に2020年11月30日時点の日本の首相のファミリーネーム（ローマ字で回答）を繋げて下さい。例えば「noda」なら、「2007-09-04_addon-security.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。
Post a comment
writeback message: Ready to post a comment.