请注意，kernel.org实际上被黑了。关于这如何不影响任何下游供应商，有一个有趣的分析。基本上，这次攻击没有产生任何显着结果的主要原因是使用了 Git 源代码控制系统。

http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/

（我似乎找不到最初的 kernel.org 消息，尽管他们的原始新闻稿埋在这篇文章中： http: //thehackernews.com/2011/09/kernelorg-server-rooted-and-448-users。 html )

好吧，既然这几乎发生了，第一件事就是写一篇关于 LWN的文章！

正如您从上一篇关于 kernel.org 的文章中看到的那样，用于分发包和代码的服务器偶尔会受到攻击，就像其他任何服务器一样。究竟能造成多大的破坏取决于妥协的程度，但如果签名密钥密码被捕获，攻击者可以签署他们喜欢的任何包，将其作为分发包分发的包传递出去。

这样做的结果是客户端系统会接受更新，而用户不会更聪明 - 至少在发行版实现并发送更新的密钥并调查已更改的内容之前。

不幸的是，您（最终用户）可以采取的措施来防止这种情况发生 - 您知道的唯一方法是分析您的系统是否存在恶意行为并（希望）找到它。

在你认为这是一个仅限 Linux 的问题之前 - 请记住，许多公司会从服务器推送更新，或者依赖中央签名代码。同样的风险也适用（如果不签署，风险会更糟）。已经发生了对根 CA 的妥协 ，其后果非常相似——你最终得到了一个看起来有效的连接，但你实际上无法信任。

所有这一切都归结为具有单点故障的中央信任模型，而不是试图分散问题的信任网络模型。然而，信任网络模型有其自身的问题。

那么显然它会很糟糕。

有减轻因素；镜子、签名、校验和等。在大多数情况下，将这类东西隐藏超过一两个小时是很困难的，所以这类东西往往会在造成任何损害之前被发现并补救。

更麻烦的是，如果一个包的官方源代码存储库被黑客入侵并且源代码被修改。这已经发生在一些项目中，并且是进行分散式开发的主要卖点，就像您在 Linux 内核中看到的那样。这样就没有中央存储库可以破解。

我假设您在谈论分发软件的“镜像”？

大多数现代发行版都使用数字签名来防止镜像上的包被篡改。

当发行版开发人员构建一个包时，他使用发行版信任的密钥对其进行签名。然后可以将包分发到镜像，只要：

1. 检查包签名
2. 签名链没有受到损害

您可以相当确定您下载的包是开发人员添加到发行版中的包。