For caching purposes.

I’m having trouble finding the exact details of the problem, but http was supposed to be fine because it does a signature check of the package (that’s what the apt keys are for), meaning even if someone were to MITM you, the signature check would fail.

If I’m understanding the Debian security announcement correctly, it says there’s a way a redirect can cause a package to replace another. I don’t understand why this in itself is a problem unless it’s also bypassing the signature check (which I’d expect to happen as part of the installation process and after download completion, not prior to download completion), but in that case it seems to me the heart of the bug isn’t using http as http allowing MITM and manipulations is a given. The actual issue is bypassing the signature check, but I’ve not seen any articles explain that.

EDIT: now that I think about it, you can just download .deb outside of apt and install without a key, so maybe it isn’t checked as part of install and only download, but that would still mean that the root problem itself isn’t on the http/redirect side, it’s the bypassing of the signature check. I want to look in to how apt functions more deeply.

EDIT: I think I got it. If you download 2 packages (A and B) as part of a single apt run, package A completes and passes signature check, package B gets a redirect such that it effectively gets renamed to A, when B completes, the signature check is not rerun on the file name of A, but what B should have been. A is replaced with a file that hasn’t passed signature check and gets installed without a further check. I’m not suoer confident, but this is my interpretation of the Debian security announcement. This does out the problem more in the handling of http redirects because it’s not updating the file name that’s used for the sig check. I think I need to look at the code to be sure.