今日、このトピックを見ました: Third-party plugin repository hijacked
このリポジトリの問題が「解決」されたのは良いことですが、本当の問題はまだ残っています。署名の方法と、署名を検証するためのキーのソースは何でしょうか。
そこで、その問題に対する最初の試みは、gitの組み込み署名メカニズムを利用することです。Discourseは、インストールされたプラグインの署名者を追跡する必要があります。それが変更された場合、管理者に警告を発するべきです。
これは明らかに多くの欠点があります。
署名者のキーをどこから取得するのか？ plugin.rbとabout.jsonのメタデータ。キーサーバーは良いですが、かなり複雑です。あるいは… meta.discourse.orgをキーサーバーとして機能させ、著者は公開キーを登録する必要があります。
最新のコミットのみを検証する？おそらく十分でしょう。盗まれたキーについてはあまりできません。
しかし、キーが盗まれた場合、失効をどのようにチェックするのか？ metaがキーを提供する場合、その問題は解決される可能性があります。
これは管理者UIには素晴らしいですが、Dockerコンテナ内のプラグインインストールについてはどうでしょうか？以前に受け入れられた署名キーを共有に保存し、再構築に検証ステップを追加します。おそらく、システムをダウンさせるのを防ぎ、その後クローンを拒否するためのビルド前のチェック。そして、その間に誰かがリポジトリを改ざんした場合に備えて、チェックアウト後のチェックも行うべきでしょうか？
署名されていない古いリポジトリについては？コンテンツが検証できないという大きな警告。+ はい/いいえ/キャンセルプロンプト
「いいね！」 11
Ethsim2
(Ethan )
2
には責任があります。サーバーオーナーは、サーバーが目的のコードをロードするようにする必要があります。それはGitHubに責任を転嫁するにしても、TLD（例：.com）に責任を転嫁するにしても、あるいはさらに下流に責任を転嫁するにしてもです。
「いいね！」 1
もちろんです、絶対に。
ただし、管理者としての私の作業を容易にしてください。プラグイン開発者として、あなたの作業を容易にしたいと考えています。
現在、アップグレードはソースURIに絶対的な信頼を置いています。これは私にとって問題です。なぜなら、ソース（GitHub）は信頼できないことが示されており、特にコンテナの再構築の特定のステップでは信頼できません。信頼関係に変更があった場合は、管理者である私に警告してください。
管理者として、私はすべてのプラグインまたはテーマコンポーネントを追加する前に、それらをすべて審査しました。その後、Discourseは審査に関してほとんど、あるいはまったくガイダンスを提供してくれません。今日、コンテナを再構築する必要があり、これによりすべてのプラグインが再クローンされます。リリースをピン留めする高度な変更を行わない限り、私はほとんど制御できません。
これは、メンテナンスを行う際に、十分に休息したソフトウェア開発者である私にとってはうまくいくかもしれませんが、かなりの制約があります。Discourseを優れたディスカッションプラットフォームにすることに加えて、ディスカッションのための技術的に安全なプラットフォームにする必要もあります。侵害されたプラグインは深刻な損害を与える可能性があります。侵害されたテーマコンポーネントは重大な損害を与える可能性があります。
「いいね！」 5
RGJ
(Richard - Communiteq)
4
これは非常に理にかなっています。JavaScriptにはSRIがあり、WindowsにはMS Authenticodeがあります。
NPMやRubyGemsなど、多くのサプライチェーン攻撃がありました。
私が懸念しているのは、プラグインやテーマコンポーネントが「承認」されるための障壁があることです。Microsoft Smartscreenが、単一の開発者からのあまり知られていないソフトウェアの実行をユーザーに阻止する方法のように。
「いいね！」 5
this postで言及したように、追加の依存関係も攻撃ベクトルになります。
プラグインでは、追加のGemをインストールするのは非常に簡単です。これは管理者にとってはほとんど見えません。
さらに、このアプローチにはSRIがないようです。Rubyのエコシステムにはあまり詳しくないのですが、Gemリポジトリは不変ですか？