Home > Latest topics

Latest topics > 拡張機能の厳密なバージョンチェック

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

拡張機能の厳密なバージョンチェック - Oct 02, 2005

もとひこ氏の日記でとりあげられていた、Bug 310644 - Firefox/1.4.1 app provided ext's have minVersion and maxVersion 1.4……つまりFirefox 1.5以降では今までの運用ポリシーを覆しますよと。今までは1.0.7でも1.0.0でも「同じ1.0.x系」ということで拡張機能の対応バージョンチェックを行わなかったけれども、今後はマイナーバージョンやリビジョン違いでも厳密にチェックしますよと。そういうことらしい。

まあそのポリシー自体には僕は結構異論無かったりする。関数の動的書き換えで動作してる拡張機能が、元の関数の仕様がセキュリティのために変更されてて動作しなくなったり、そういうケースが実際に起こりうることを考えれば、これは本来厳密にしておかなくてはいけないところだと思う。元作者がその拡張機能を開発継続できなくなったとしても、誰か別の人がメンテナンスを引き継いで新しいFirefoxに対応させていけばよい。

……というのは現実を無視した理想論だ。現実には、セキュリティアップデートの影響を受けるような拡張機能は少数派だし、元作者に見放された拡張機能は誰も引き継いでくれないことがほとんど(Sageとか後継プロジェクトが動いてるのは希有な例ですよホント)だし、そもそも公開時にライセンスを明記してないから勝手に後継プロジェクトを始められないという例がほとんどだし(勝手にやれば、著作権侵害でいつかお縄を頂戴することになりかねない)。

何よりの問題は、こういう重大な決定を1.0.0公開までの間に済ませていなかったり、もとひこ氏の言うとおり、誰にも言わずにこっそりポリシーを変えて「いや、今後はこういう事に決まったから、その要望は受け付けられない。」みたいな態度を平気で取るMozilla Foundationのコア開発者の駄目さ加減。あと恨みついでに言えば、リリース予定を一度として守れたことがない腐ったプロジェクト管理。その辺だよな。

分類:Mozilla > XUL, , , , 時刻:13:46 | Comments/Trackbacks (5) | Edit

Comments/Trackbacks

感想

ちゃんとそのつどチェックというのは理想的ですが、たとえばテーマなんかセキュリティフィックスで何をチェックすればいいんでしょう……
たしか以前のもとひこさんの日記によると、その時点で存在しないem:maxVersionは当然現物で確認できないからつけちゃいけなかったと記憶しています。
Torisugariさんにでも伺わないとはっきりとは分かりませんが、UMOの拡張やテーマのチェックは、ボランティアのXULとかMozillaとかに詳しい人(ということは拡張作者のかたが多いでしょう)が一つ一つごとに、そしてその一つ一つの更新ごとに手作業でされてるっぽいので、こんなことにしたらチェックする人の負担が大きくなるだけのような。というか、現行のこのチェックシステムでも、XULとかMozillaとかに詳しい人は限られているので、拡張やテーマが多く登録されて、その更新が頻繁にされるFirefoxにとって良い状態になればなるほど、システムとしては破綻していくのは容易に想像がつくのですが。
ライセンスについては内部でさえQuteの件とかで揉めてますし、インストール時にパッケージ内の指定された文書(license.xmlとか)を強制チェックして、そのファイルが存在しない場合はインストールできないとかでもいいような感じもします。

Commented by くでん at 2005/10/02 (Sun) 16:30:12

ソース

> たしか以前のもとひこさんの日記によると、その時点で存在しないem:maxVersionは当然現物で確認できないからつけちゃいけなかったと記憶しています。
ソース: http://www.mozilla.org/projects/firefox/extensions/update.html
> Automatic Extension Update Checking
> ... You should never set maxVersion greater than the current Firefox release.

Commented by もとひこ at 2005/10/02 (Sun) 19:32:16

著作権侵害

作った人と連絡が取れるのであれば連絡を取れば言い訳で。
著作権侵害は日本では親告罪だし、作った人と連絡の取れない場合の勝手な引き継ぎで訴えられたら止めればいいという考えは甘いのでしょうかねぇ…(いや、ライセンスをPublic licenseに変更するのとかは問題あるだろうと思いますが(二次著作物扱い?)、mozexとかMSN Messanger互換な拡張とか消えてった拡張も多少はあるし。)
ライセンスが明記されてない物は日本では作った人が全権保有ですが海外ではどうなのかなぁ…

#関数の動的書き換えは邪道なんだから割り込むリスナを増やすパッチを本家へ出せばいいじゃない…と言ってみるテスト。(そういう俺もFiler拡張で邪道な事しまくってる罠)
#それとMPLはライセンスヘッダが面倒過ぎてライセンスの明記なんてとてもとても(ryという側面もありそう。(ていうか俺にある。)
#MPL/GPL/LGPLへの再ライセンス化を許可するというライセンスってライセンス的におkなのかな…?
#GPLへの再ライセンスに問題ありそげ?

Commented by at 2005/10/02 (Sun) 21:19:50

UMO

> こんなことにしたらチェックする人の負担が大きくなるだけのような

UMOでは対応バージョンを変えるだけなら、レビューを受ける必要はありません。実際にその機能を使ったことがないので、想像ですけど、中身のinstall.rdfを勝手に書き換えてくれるんだと思います。 

ちょっと探してみたんですけど、公式コメントは見つけられませんでした。
http://forums.mozillazine.org/viewtopic.php?t=301827
に書いてあるGUI云々の話です。

Commented by Torisugari at 2005/10/06 (Thu) 21:20:12

Re:UMO

はじめまして。ご返事いただきありがとうございます。
なるほど、たしかにメニューからバージョン名を設定できるようになっていますね。何度も見ていたはずなのに意識からすっかり外れていました。ということは、各自でチェックして変更をすればいいわけですから私の取り越し苦労だったみたいです。
この機能は機会があったら試してみたいなと思います。

Commented by くでん at 2005/10/07 (Fri) 20:40:17

TrackBack ping me at


の末尾に2020年11月30日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2005-10-02_versioncheck.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2020年11月30日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき