您提到 CCleaner，因此与链接到是否会阻止 CCleaner 妥协？简短的回答是它不会阻止这种特殊的妥协。

这给我们提供了提供哈希的第一个问题：我们信任谁来签署构建，以及我们信任他们检查什么？签名是否仅代表可能被破坏的官方构建服务器？或者它是否代表某个预信任方的实际安全审计？

但是，这种散列可以防范其他攻击 - 例如，提供篡改构建的受损或欺诈镜像。在这种情况下，主项目页面发布散列就足够了，可以根据任何镜像提供的下载来验证散列。

然而，这将我们引向第二个问题，这是密码学的难题之一：密钥分发（或者，在这种情况下，签名分发）。

对于未签名的哈希，您只是信任显示该哈希的页面未被篡改。乍一看签名哈希似乎更好，但您仍然必须从某个地方下载公钥，因此您仍然信任该密钥的来源。如果攻击者可以将用户引导到虚假下载页面，他们可以添加指向他们选择的公钥的链接，并且用户将通过验证受损下载的哈希来获得虚假的安全感。

另一种方法是为多个不同的应用程序拥有一些您信任的中央权威 - 这是 Windows 驱动程序签名、Linux 包管理器和手机应用程序商店背后的原则（以及用于 HTTPS 网站的证书背后）。现在你有一个新问题：你为什么相信那些中央当局？他们是否直接审核您正在下载的文件的源代码和构建过程？还是他们基于实际生产软件的一方的某些保证，通过会签证书委托信任？另外，您仍然需要以某种方式获取根公钥 - 大概当您安装操作系统/应用商店/包管理器时，它已包含在某些受信任的安装媒体中。

最后，发布哈希对于大型项目最有用，其中：

• 同一用户可能会使用相同的公钥下载并验证多个版本或不同的应用程序；
• 并且，公钥的来源可能与提供下载的服务器不同（不同的服务器或某些物理介质）

但即便如此，它也无法修复所有漏洞，正如 CCleaner 所展示的那样。给用户一种虚假的安全感是有危险的。

他们是这样！许多 Windows 可执行文件具有由 Microsoft 信任的 CA 签名的内置证书。操作系统在运行软件之前会检查此证书。可以进行其他配置以防止未签名的软件运行，而不仅仅是显示警告。此外，可以创建更进一步的限制，只允许运行 Microsoft 签名的可执行文件，而不仅仅是由 Microsoft 信任的发布者签名的可执行文件。

Linux 和相关操作系统尚不支持此功能（ELF 与 PE32 不同，不支持嵌入式证书），但很少有人这样做，因为大多数软件安装都是使用其本机包管理器完成的，该包管理器通常会验证软件。在这种情况下，没有来自受信任 CA 的证书。相反，签名由软件存储库的维护者提供，并在安装期间由包管理器验证。

对于包管理器不一定提供且不能具有嵌入式签名的安全敏感下载，通常会提供签名哈希。尤其是可引导的 ISO 映像就是这种情况，尽管有些只提供未签名的哈希值，而不是签名的哈希值。不幸的是，仍然有许多通过不安全连接提供的可执行文件没有签名，这仅仅是因为网站管理员不了解完整性的重要性并低估了泄露的风险。

因为大多数用户无论如何都不会检查哈希。

这将需要一个通用的下载协议来自动化并强制执行签名验证，才能真正遏制恶意软件的传播。

这仍然不是完美的——被黑的服务器也可以发布不同的哈希值。与 Windows 驱动程序一样，对软件本身进行签名可能更有可能产生影响。两者都可以做到。

我看到与linux相关的站点上显示了更多哈希（通常是 md5） 。主要是在提供iso时。

您不想从损坏的 ISO 安装操作系统，是吗？

您还可以在下载页面上找到 Windows 10 ISO 的哈希值。

哈希在这里仅用于检查下载文件的完整性。

当您需要检查文件是否未被篡改时，严重站点，请提供您需要使用 GPG 密钥检查的 GPG 密钥签名。例如，tails.boum.org 就是这样做的。