This is not a -1, but I think it'd be useful to have some perspective here, rather than just the "no HTTPS the sky is falling" view.

> HTTPS everywhere is now a best practice on the web, and through the US government and among major service providers.

I don't agree with this as a justification. "HTTPS everywhere" has come out of a specific need. The justifications for its implementation do not automatically hold "everywhere", especially outside of web apps. That's not to say that HTTPS shouldn't be implemented here, just that the argument that "it has been justified elsewhere, therefore it is justified here" is not a valid one, especially because in the other cases no HTTPS means no protection, whereas we already use signed packages. Thus this particular argument is hardly "compelling". The pros and cons of HTTPS implementation for package repositories should be considered on its own merits.

> * network attackers can't see what packages you're downloading and the specific software versions, thus profiling the server and assisting the targeting of vulnerabilities and zero-day attacks against it

The published packages have well known sizes, so I think attackers probably can infer what an individual downloads based on size. That doesn't mean that we should not have HTTPS, but rather that it should not be assumed that HTTPS downloads of packages would automatically be private.

If you really want privacy of the packages you download, it would be more effective to operate a full local repository mirror.

> * a sophisticated attacker with possession of a compromised package signing key can't leverage a "QUANTUM insert"-esque technique to redirect to a malicious .deb

A "a compromised package signing key" sounds like a tall order to me. Far harder than a compromised mirror private SSL key, since the former doesn't need to be kept on machines with widespread exposure to the world. I suppose there's no harm in being protected by both, though, since the two would probably need to be compromised separately - though I suspect that so many other attack vectors would be opened up by a compromised packaging signing key that HTTPS to your mirror probably won't help you anyway. For example, what about "flashplugin-installer" (for those who have multiverse enabled) and its download of a binary blob outside the usual packaging system, only verified by a (package-)signed hash? If a packaging signing key were compromised, you'd get little protection from an HTTPS apt repository without this transfer also being on HTTPS.

> * an attacker able to passively sniff the network traffic would not be able to use fingerprint techniques to find/identify servers installing an exact set of packages specific to an environment the adversary is searching for

Note the fingerprint-by-size issue above - I don't think HTTPS will help you against sophisticated attackers here. Run a full local repository mirror instead if you care about this.

> * it makes impersonating an apt repo (for example with the goal of blocking people from receiving security updates) more difficult

Somewhat true I guess, though note that although I don't see it being used, apt is capable of some level of protection for this by Release files having expiry dates. See "Check-Valid-Until" in apt.conf(5) for details. But impersonators would be able to get away with it for a while, so an HTTPS mirror would improve this by informing users of the failure immediately rather than after the expiry time.