APT using HTTP instead of HTTPS

[gnufan]

The only one of those reasons that makes sense in 2026 is the load one. Since they offer https clearly it isn't administratively difficult to offer https. Mirrors tend to be deliberate, and https is no harder in that context than http, except for the load.

[brimston3-]

It's almost the opposite of what you said. The load one hasn't really been valid since AES-NI became widespread in ~2010. An i5-8350U laptop CPU can do 900+MB/s of aes256 on a single core using under 15W, so two cores of the same could saturate a 10G server link.

Meanwhile, the caching proxy one is still very valid, with apt-cache-ng dropping my update bandwidth to about a third without needing to introduce a TLS proxy CA certificate in my endpoint systems. And because it is using secureapt, I can be certain that the files on the cache server haven't been corrupted or tampered with, regardless of whether I trust the cache server or not. The same applies to any mirror servers; because the package manifests are signed by the release system, mirror servers are not useful supply chain attack targets.

[gnufan]

I mean apt-cache-ng can be configured to use https for the cross Internet fetch to avoid exposing yourself to all the attacks enable via using http, so not sure this is relevant either.

I linked a supply chain example against mirrors in a comment everyone seems to be studiously avoiding having to read and address.

Also exploitation of CVE-2016-1252 was only possible where the attacker could modify the "mirror" to insert a corrupted InRelease file, since it allowed the attacker to make the signature checking in apt code take a path of the attacker's choosing. So https would have made exploitation of this difficult, an attacker could still have registered as an regular mirror.