我今天看到了这个话题：Third-party plugin repository hijacked
很高兴这个仓库的“问题”已经“解决”了。但真正的问题仍然存在。你如何签名，以及用于验证签名的密钥的来源是什么。
所以，我解决这个问题的第一个尝试是利用 git 内置的签名机制。Discourse 然后需要跟踪已安装插件的签名者。如果发生更改，它应该会警告管理员。
这显然有很多漏洞。
从哪里获取签名者的密钥？在 plugin.rb 和 about.json 中添加元数据。密钥服务器（Keyservers）很好……但相当复杂。或者……meta.discourse.org 作为密钥服务器，所以作者应该注册他们的公钥。
只验证最近的提交？可能足够了，无法处理被盗密钥的问题。
但是如果密钥被盗了，如何检查吊销？如果 meta 提供密钥，这个问题就可以解决了。
这对管理员界面来说很棒，但 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 个赞
正如我在这篇帖子中提到的，另外拉入的依赖项也是一个攻击向量。
在插件中安装额外的 Gems 非常容易。这对管理员来说几乎是看不见的。
此外，这种方法似乎没有 SRI。我对 Ruby 生态系统不太熟悉，Gem 仓库是不可变的吗？