signing akahukuplus

赤福プラスを Unlisted な拡張として AMO に提出し、署名を付けてもらった。

この際、機械的な validator が走り、ソースが検証される。この検証に引っかかった場合即時署名はされないが、AMO の中の人によるレビューを申請することはできる。一方、検証にすべて通れば即時署名が施される。いずれにしても署名された xpi は AMO の自分のアカウント内に保存されるのでそれをダウンロードして別の場所で公開すればいい。

赤福プラスがこの検証にすべて通ったわけだが、前に書いた通り検証を行う validator は本当にひどい出来なのだった。ひどい出来だし、意味のない設計方針に基づいて作られている。

たとえば validator は eval や、Function や、innerHTML や、insertAdjacentHTML や、引数がリテラルではない createElement があると即時署名を拒否する。そんなわけで

const FUN = '';
var fun = some_decrypt_function(FUN);
var f = window[fun]('alert("wow!");');

のような感じでとにかくソースからイケないメソッドやプロパティ名を隠す。すると、validator はころっと騙される。

ああ、嫌なコードだなあ。嫌だし、自動検証に対してしか提出しない場合にのみ許される手法だ。これを preliminary review とかに提出したら必ず「この処理って何やってんの?」と聞かれるし、そして拒否されるだろう。

そもそもこの手のチェックに意味があるんだろうか。eval や innerHTML 自身が悪というわけではないのだ。使い方の問題なのだ。AMO の手で署名を付けてその拡張の生殺与奪権を握っているわけなのだから、イケない拡張がイケない使い方をしているなあと判明した時点でロックダウンすればいいんじゃなかろうか。

Opera から移行して以来、努めて愛そうとしているけれど、残念ながら Mozilla にもその製品にも、本当にがっかりさせられることが多い。

2 thoughts on “signing akahukuplus

  1. Operaの赤福プラスで手書き出来るようになる機能はいつ頃来ますか?
    そもそも作る予定はなかったりしますか?

  2. Pingback: 赤心慶福 — Tegaki

Leave a Reply

Your email address will not be published. Required fields are marked *