HTTP is very useful for caching and mirrors for Linux distributions because signatures are checked by package managers outside of the transport protocol.
And additionally signature verification provides far better security than HTTPS on its own because a compromised mirror cannot compromise the signature.
What about confidentiality of the package downloads though?
e.g. Snoop the traffic, notice they are downloading a fix, they probably don't have it, automatically attack them before they apply it.
HTTPS doesn't protect much from that either. A third party can figure out what you just downloaded based on the download size, since the size of package files are well known. Even if there is some uncertainty between sets of packages it could be inferred from your other downloads, since decisions on what to download are based on known logic (dependency tree, what the victim likely had installed before, etc).
I suppose in your case the window would be smaller using HTTPS, as the package downloaded could probably be inferred only after the download is complete. But your method would need automation anyway, so I don't think the difference in timing would really matter in practice.
But if you are in the position to automatically attack someone, why wait to see if they are downloading a fix? Why not just try to attack with known recent vulnerabilities anyway?
