这很简单：Ubuntu 提供例如http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/，但不提供http s ://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/。你对此无能为力。哪有镜子比原点更安全？

如果您想查看https://ppa.launchpad.net/ ，请向https://bugs.launchpad.net/提交错误报告，但不要抱太大希望。

您提出了一个大胆的主张，即在代码签名机制之上将 HTTPS 添加到 PPA 镜像是一种安全改进。让我们看看这两个东西在做什么：

代码签名

我不熟悉代码签名在 Ubuntu / apt 中的工作原理，而且我在 Google 上也没有成功找到它。软件包是由开发人员签名的，还是由镜像本身签名的？如果有人有链接，我将不胜感激。我假设它们是由镜子签名的，因为这样更有意义。

所以，安全模型是你有一个.deb你要安装的文件（你得到它的方法无关紧要），你可以验证包上的签名以确保它是真实的。如果没有攻击者窃取私钥并签署他们自己的版本，这似乎是无懈可击的。

HTTPS/TLS

这增加的价值是服务器可以加密证明它就是它所说的那个人，并且所有通信都不能是中间人。让我们详细看一下：

案例 1：PPA 代码签名密钥或 HTTPS 服务器密钥均未泄露

万事皆安。你得到双重保护。HTTPS 没有增加任何价值。

案例 2：PPA 代码签名密钥未泄露，HTTPS 服务器密钥泄露

这相当于当前没有 HTTPS 的做法。因此，攻击者可以 MitM 您的连接https://ppa.launchpad.net，因此 apt 将无法为您提供该.deb文件的恶意版本。但是您将无法安装它，因为签名无法正确验证。HTTPS 没有增加任何价值。

案例 3：PPA 代码签名密钥泄露，HTTPS 服务器密钥未泄露

攻击者将无法 MitM 您与https://ppa.launchpad.net. HTTPS正在增加价值。

案例 4：两个密钥都被泄露

你有麻烦了。HTTPS 没有增加任何价值。

HTTPS 增加价值的唯一情况是 PPA 签名密钥被泄露，但服务器 TLS 密钥没有泄露。这种情况发生的可能性有多大？显然，负责该系统设计的人员并不认为这是一个重大威胁。正如@kay 在那个答案中所说，如果你想对这个问题施加压力，然后提交一个错误。

顺便说一句，将 HTTP 用于具有内置加密的协议的设计模式相当普遍并被接受。这是一个非常相似的协议设计，例如用于管理证书的 CMP 或 AIA：这些协议不需要通过 TLS，因为协议本身具有内置的加密保护。此外，您要验证的原始实体是 CA（或在本例中为代码签名者），您从哪个特定镜像获取文件几乎无关紧要。（将此与 TLS 设计的用例进行比较，例如，连接到www.facebook.com服务器的身份是重要部分的地方）。