Skip to content

プラグイン読み込みの仕様変更の草案 #1325

@nmaya

Description

@nmaya

#1286 から移動した。

  • 別件なので
  • 元 issue が close されたら埋もれるので

ありがとうございます。

仕様を考え直しました。
次のようにプラグインを読み込むはどうでしょうか?

  • TTX*.DLLの一覧(ファイル一覧)を作る
    • HomeDir(個人設定のあるフォルダ, %APPDATA%\teraterm5) の TTX*.DLL (*1)
    • ExeDir(ttermpro.exeのあるフォルダ)の TTX*.DLL
    • 両方に同じファイル名があったら、HomeDirのほうを優先
  • ファイル一覧から、ロングファイル名でTTX*.DLL以外のファイルを削除する(大文字小文字判定なし)
  • TERATERM.INI の [Plugin] セクションの一覧(INI内一覧、パスなし)がある?
    • ない場合
      • ファイル一覧のDLLを全てを enable 扱いとする(初期化)
      • TERATERM.INIを保存すると、すべてenableとなる
  • INI内一覧に存在しないファイルが、ファイル一覧に存在する?
    • 存在する場合、disableとする(*2)
  • 次のファイルをロード
    • ファイル一覧に存在、かつ
    • INI内一覧で enable

ポイント

  • *1 ユーザー用プラグインフォルダ
    • 将来こうするのが良いかなと思います
    • 簡単そうなら入れてしまってよさそう
  • *2 新しく置かれたプラグインはdisableとなり読まれない
    • いまのところ従来通り読めるほうがよいか?
      • 新しく見つかったプラグインの扱いをenable/disableどちらにするか設定をつくるのがよいか?
  • TERATERM.INI の [Plugin] セクションの一覧
    • パスなし、ファイル名のみ
    • enable又はdisableのどちらかになる、未指定状態はなし
  • ファイル名の比較は大文字小文字は同一とみなす

ファイル名を円マーク区切りではなく/区切り

ファイル名抽出の時に考慮必要ですね。

署名関係も入れて、

  • 署名の有無を一覧に表示(表示のみ)
  • 署名有りのみロード / 有無は無視してロード

もあったほうが良いか?と思っていました。
どうでしょうか?

Originally posted by @zmatsuo in #1286


仕様検討有難うございます。
自分は、以下がひっかりました。
両方に同じファイル名があったら、HomeDirのほうを優先

ExeDirを優先にして同名があったらワーニングダイアログ表示かなと思いました。
理由は、同名のHomeDirのPluginはバージョンもアーキテクチャも不明です。
そのため、HomeDirに古いPluginが残っていた状態で Tera Term をアップデートしても
同名の付属Pluginは対象にならないので更新された機能は使えません。
バージョンアップインストールしても機能が動作しない問い合わせが増える
未来が容易に想像できるからです。

ファイル一覧のDLLを全てを enable 扱いとする(初期化)

ExeDirのPluginはenableでいいと思いますが、
HomeDirのPluginはdisableのほうが安全ではないでしょうか。

ファイル名抽出の時に考慮必要ですね。

細かくは知りませんが、ディレクトリトラバーサルなどできないように
二重・三重のチェックが欲しいかと思います。

署名関係も入れて、

自分は署名に関しては見識がないのでわかりません。
多分ローカルで使っている分には署名する必要もないと思っています。
バージョンアップで署名が変わった場合はどうなるのだろう。

Originally posted by @tomo3136a in #1286


ExeDirを優先にして同名があったら

WindowsのDLL読み込みの優先順位みたいな感じで、
優先度が高いところから読み込まれるイメージです。

別フォルダの同名プラグインは、読み込めてよい気もしますが悩ましいです。

他の方の意見を待ってみましょう。

HomeDirのPluginはdisableのほうが安全

安全そうです。

スパムメールでも正しく署名が入っていたりするのと同様で、
署名されているから安全と断定はできないです。
でも、判断材料になります。
まずは、設定のプラグインタブの一覧に署名あり/なしを
表示できるようにすれば良いかなと思っています。
(右クリックのメニューからファイルのプロパティが出せればとてもよさそう)
簡単なら入れたいですが、大変そうだったら別issueでしょうか。

ビルドスクリプトを修正して
プラグインにも署名するよう修正する必要がありますね。

Originally posted by @zmatsuo in #1286


第一感ですが、以下のように感じました。

両方に同じファイル名があったら、HomeDirのほうを優先

HomeDirのほうを優先 で良いと思いました。(利用者の自由度を上げることが出来るため)

ExeDirを優先にして同名があったらワーニングダイアログ表示かなと思いました。

HomeDirのPluginの初期値がdisableなら、ワーニングダイアログ表示までは不要と思いました。

理由は、同名のHomeDirのPluginはバージョンもアーキテクチャも不明です。
そのため、HomeDirに古いPluginが残っていた状態で Tera Term をアップデートしても
同名の付属Pluginは対象にならないので更新された機能は使えません。

利用者があえてそうしている場合も考えられます。(例 標準DLLをフォークして機能追加している場合)
同名の dll を HomeDir に配置して使用する利用者に対しては、アップデートのケアまでは不要と思いました。

バージョンアップインストールしても機能が動作しない問い合わせが増える
未来が容易に想像できるからです。

ご配慮ありがとうございます。

HomeDirのPluginはdisableのほうが安全

はい、署名されている場合でもHomeDirのPluginの初期値はdisableが安全と思いました。

Originally posted by @hkanou in #1286


検討有難うございます。
主題から離れてしまっていますが、
利用者があえてそうしている場合も考えられます。(例 標準DLLをフォークして機能追加している場合)

そう。そこが問題な箇所だと思いました。
常にメンテナンス(もしくは詳細に引継ぎ)していれば問題ないのかもしれませんが、
多くは最初にセッティング・その後放置、忘れたころにアップデートになると思います。
(そして、なんかおかしくて悩む)

では、ExeDirかHomeDirかどちらのプラグインで動作しているか明示(色分けとか?)してはどうでしょうか。
そうすれば、問題の切り分けの一助になるかと思います。

Originally posted by @tomo3136a in #1286


あまりまとまっていないのですが、議論を追っていてなんとなく思ったことをアウトプットしておきます。

HomeDir にプラグインを配置することについて

DLL の読み込みディレクトリが増えるということは、攻撃者がDLLを配置できる箇所が増えるということです。
しかも HomeDir という、%PROGRAMFILES% とは違って権限が必要ないところにです。
「ダウンロード」フォルダほど一般的な箇所ではありませんし、そんなこと言っていたら機能を追加できないのですが、そういうものを作ろうとしていることは意識した方がよいと思います。

優先順位

本当にユーザが配置したとみなすのであれば、HomeDir が優先でよいと思います。
この「優先」というのは、「HomeDirのを先に読み込んで、同名のものがExeDirにあっても読み込む」ではなく、「HomeDirのを先に読み込んで、同名のものがExeDirにあったら読み込まない(もしくは強制disableとしてリストアップだけされる)」でよいでしょうか?そうしないと「標準DLLをフォークして機能追加している(インストールして、カスタム版も配置している)場合」に二重になりませんか?

状態の値

「未指定状態」を削除して、enable/disableだけにする提案がなされています。
一般的にenableには「明示的に有効にした」と「デフォルトで有効になっている」のどちらも含まれると思いますので、現状の「未指定状態=未指定で有効になっている」をenableに統合するのは合理的に思います。
ただ、上記のように「強制disable」が起こったり、「HomeDirのは明示的に書かないとenableにならない」だとすると、「指定してenableか指定せずにenableか」の状態を分けておき、それを表示したほうが良いようにも思えます。

アップデートのケア

プラグインの互換性が壊れるのってどのタイミングでしょうか。
プラグイン側に「このプラグインのビルド時の互換バージョン」を拾えるような物を作り、「プラグイン一覧でバージョンを表示する」or「本体のプラグイン互換バージョンと比較してずれていたらプラグイン情報だけ拾って強制disable」とか可能そうではあります。
たしか以前は tttset を変えるたびに共有メモリ名をインクリメントしていたと思いますが、今はバージョン番号を使って自動的に上がってしまうので使えませんね。
これは単なる思いつきで、同じ労力をかけるならより優先度が高い物があると思います。プラグインがどれだけ世の中にあってどれだけ使われているかはっきりしませんが、ユーザー全体からするとわずかだと思いますので。

Originally posted by @nmaya in #1286


一般的にenableには「明示的に有効にした」と「デフォルトで有効になっている」のどちらも含まれる

今の実装が

  • enable
  • disable
  • unspecified(未指定なのでenable)

となっていて、
unspecifiedからenable/disableへ変更すると、unspecifiedに戻れない
となっています。

これを

  • enable
  • disable

の2値にして、代わりに

  • 初めて(設定が無い状態から)の起動時、全部 enable
  • リストにないプラグインは disable

とする、というのが今回の提案です。

設定が2値なのが分かりやすそうで、
知らないプラグインは自動でdisableになって安全そう、
従来との互換性もそこそこ保てそう、です。

Tera TermセクションのVersionをチェックするとか
pluginセクションにVersionなどを置くとかで、
初回起動をチェックするのも良いかもしれません。

HomeDirのほうを優先 で良いと思いました。(利用者の自由度を上げることが出来るため)

そのように考えていたのですが、

ユーザー全体からするとわずかだと思いますので。

プラグインを作る方は、
本体がアップデートしたら追従して修正,ビルドできるでしょうし、
権限の関係で書けない/消せないと無さそうで、
ユーザー全体からすると少数派なのかなと思います。

このチケットでは
HomeDirにあるプラグイン読み込みは見送って
従来通りExeDirにあるプラグインのみ扱いましょう。

%PROGRAMFILES% は権限がなくてプラグインが置けない、という場合は
ユーザー毎インストール、野良インストールの方向でしょうか。

Originally posted by @zmatsuo in #1286

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions