你听说过古代特洛伊城的故事吗？它有巨大的城墙，将攻击者拒之门外，保护了城市的安全。然而，攻打特洛伊城的希腊军队有一个天才的想法：他们假装停止攻击，回家，同时给特洛伊人留下了一个礼物：一匹巨大的木马。特洛伊人对此礼物感激不尽，将木马拉进了城墙之内——他们不知道希腊士兵已经藏在木马中，在夜间爬出来，为他们的军队打开城门，从而葬送了城市。

希腊士兵不知道的是，他们刚刚邀请了一种所谓的“供应链攻击”——这种攻击类型在现代IT领域仍然适用。基本思路很简单：通过破坏安装或更新包来攻击IT系统。一旦这些包被下载并安装，攻击代码就会执行，系统就会受到损害。

为了防止Joomla生态系统中发生此类攻击，我们的更新服务器清单不仅支持实际文件的链接，还支持提供加密散列，证明文件内容是正确的——然而，我们如何确保这些散列没有被破坏呢？我们如何确保关于更新和实际更新文件本身都是合法文件，并由实际开发者发布的呢？

介绍“更新框架”

这就是“更新框架”，简称TUF发挥作用的地方。在核心上，它是一个软件更新分发系统的规范，允许通过没有供应链攻击向量进行安全更新。这是一个很好的设计，非常适合Joomla社区，因此一个小团队在2022年4月的CloudFest黑客马拉松期间开始实施TUF，用于Joomla核心。

六月冲刺

为了继续这个项目，2022年6月在德国纽伦堡举行了一次后续冲刺。一组9人致力于CMS中TUF所需的三个主要元素

• 我们需要一个服务器端基础设施，可以从其中检索有关可用更新的实际信息——但主要是关于托管大量文件的问题，但我们的TUF如何设置
• 核心库的仓库，需要哪些工具集来管理该仓库，以及第三方扩展的潜在集成方式
• 我们需要对现有的PHP TUF客户端进行修改，使其足够通用，不仅能够满足Drupal的需求（TUF客户端最初是为此开发的），还能满足PHP社区其他部分的需求
• 我们需要对CMS中现有的更新过程进行重构，以使用该客户端检索、验证和存储更新信息，当然也可以应用实际的更新

在冲刺期间，在所有三个领域都取得了非常好的进展

服务器端基础设施
Harald继续在CloudFest黑客马拉松期间开发的基于Docker的工具链的工作。他更新了底层的TUF实现（用Go编写），并实现了我们需要的必要命令，这些命令涉及到需要多人签名的密钥管理和发布流程。

TUF客户端
针对上游TUF客户端仓库创建了总共五个拉取请求，使TUF客户端更加通用，通过移除硬编码的依赖，使客户端更兼容我们用于服务器端设置的TUF实现。

集成到Joomla中
在黑客马拉松期间的工作得到了延续，为TUF客户端类添加了JHttp驱动程序。有了这个驱动程序，当前代码库现在能够成功检索、验证并存储从服务器团队为冲刺设置的TUF仓库中检索到的更新信息。我们还开始调整com_joomlaupdate的代码库以适应新的更新信息源。

深入兔子洞 - 在下一个冲刺中

在整个冲刺期间完成的工作中，我们越来越清楚地意识到，为了允许第三方开发者切换到基于TUF的更新方法，必须考虑扩展生态系统来构建TUF实现。然而，一开始听起来简单的事情实际上是一个复杂的问题：扩展开发者是否运行自己的仓库？如果是，如何最初获取该开发者的公钥？开发者运行自己的TUF仓库是否现实，需要深入理解这些概念？如果开发者不运行自己的仓库，我们如何构建一个对我们和第三方开发者都可扩展且可维护的“全局”扩展更新仓库？

我们还没有做出那个决定，因为需要大量的研究和测试来回答上述问题。因此，团队决定进行后续的冲刺，以做出最终的架构决策并基于此最终确定代码库。

荣誉归于应得之人

最后但并非最不重要的是，我要感谢Franciska、Niels、Stefan、Tobias、Magnus、Benjamin、Timo和Harald在冲刺期间的贡献！你们太棒了 :) 当然，我还要特别感谢Stefan作为一个如此出色的东道主，为我们提供了一个充满活力和乐趣的工作环境。