I get it to a point because it can be a chicken and egg situation sometimes, but there has got to be a better way.

theoretical model means that the transfer method doesn't matter.

Of course, that breaks if implementation checks the signatures in wrong moment

There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.

The ones I looked at could be summed up to "well the redirects are misbehaving again"

Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.

The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.

There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.

> it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used

This is what apt already does. The problem is that a malevolent source can see a client downloading package #1, then on seeing a request for package #2 it issues a redirect to a doctored package #1 and because apt stores files based on the remote name and not the requested name, it will overwrite already-downloaded package #1. The validation fails on downloaded package #2 but apt doesn't abort the install process, it simply skips it (and any dependencies) and continues to install the downloaded and previously-validated package #1.

There's plenty of ways to solve this, and none are obvious if you are unaware of this attack vector:

a) use per-package tempdir instead of per-source: no obvious benefit

b) use request package name instead of remote url filename: it would be dangerous for apt to assume that it knows better than a package mirror what the expected filename for a package is (it's strictly defined by Debian policy)

c) immediately delete downloaded package if validation fails: obstructs problem analysis and digital forensics

d) abort install process if a package fails validation: reduces resilience in the face of network errors (e.g. if the mirror is in the process of updating itself)

Not exactly sure how would a system be able to connect to Internet to download package updates but be unable to source a correct time reference from NTP?

But yes, it should probably be a Debian installer question: use HTTPS sources or not. Debian is the universal operating system but most users running a desktop or server setup should choose YES. The setups where you really want plain HTTP sources are an edge case and users setting up such systems probably already know about their special requirements, so HTTPS sources should really be presented as the default / "if in doubt" option.

Easier to put caching proxies on the path?

Who actually does that this day and age?

I do. Helps massively when seeding virtual machines using auto-install scripts.

Same. It's faster and feels respectful to not keeping hitting freely provided repos for the same packages over and over. Someone has to be paying for the bandwidth.

Thinking about it, that's not a good argument for http being the default. If you're seeding VMs, you're already in control of the config. Using a dedicated repository proxy (apt-cacher-ng? sonatype nexus? pulp? something?) might even perform better than a generic caching proxy.

Yes, I use acng. I still consider it a caching proxy, even if it's an application-specific one.

Developers

So a minuscule part of the install base that can absolutely alter system configuration to use a local mirror.

Not something that should be the default, exposing everyone to the dangers.

It's not the default, but you can install apt-transport-https and then just change the update URLs to https assuming your mirror supports that.

you can just change the urls to https, apt-transport-https isn't needed anymore, it's builtin to apt now.

I would speculate that it's inertia due to decisions made a decade or two ago, before we decided that everything should run via HTTPS.

you can inspect the traffic even without ssl inspection