I think that the biggest issue with apt repositories not using https is that attackers can block updates and censor which packages can be installed.
Here's a story: Once I was on Amtrak, the train system run by a US federal government agency, and noticed that the wifi was being censored. I wanted to try to figure out exactly how it was being censored using OONI Probe [1], but I didn't have it installed. So I attempted installing it, but the Amtrak network blocked the download of some of the dependencies, so I failed in mapping the censorship that trip. I figured out that the network blocked all http downloads where the content-length header was greater than 10mb (to prevent bandwidth abuse or something), but Amtrak wouldn't have prevented me from installing this if the apt repositories used https.
This is more innocent that other attacks could be. An attacker could prevent the installation of security updates, or of specific packages that they didn't want people using, such as enigmail, pidgin-otr, anarchism, etc.
Fingerprinting installed software is also a big issue. Robie makes a good point that https won't necessarily prevent that, because of package file sizes, but I still think transport encryption is the first step to solving that problem (e.g. then packages could add padding). And using https would require the attacker to maintain a database of package versions and file sizes, for all repositories that victims maybe using, including arbitrary PPAs, rather than just looking for package names and versions in the URLs.
But also, while it's true that "other things use https" isn't necessarily a good justification for apt repos to follow suit, I do think it's past time that we completely stop using plaintext transport protocols for anything. Even when you're using http to download signed things (like software packages, or PGP keys from key servers), transport encryption makes network attacks, both passive and active, much harder and makes users safer.
I think that the biggest issue with apt repositories not using https is that attackers can block updates and censor which packages can be installed.
Here's a story: Once I was on Amtrak, the train system run by a US federal government agency, and noticed that the wifi was being censored. I wanted to try to figure out exactly how it was being censored using OONI Probe [1], but I didn't have it installed. So I attempted installing it, but the Amtrak network blocked the download of some of the dependencies, so I failed in mapping the censorship that trip. I figured out that the network blocked all http downloads where the content-length header was greater than 10mb (to prevent bandwidth abuse or something), but Amtrak wouldn't have prevented me from installing this if the apt repositories used https.
This is more innocent that other attacks could be. An attacker could prevent the installation of security updates, or of specific packages that they didn't want people using, such as enigmail, pidgin-otr, anarchism, etc.
Fingerprinting installed software is also a big issue. Robie makes a good point that https won't necessarily prevent that, because of package file sizes, but I still think transport encryption is the first step to solving that problem (e.g. then packages could add padding). And using https would require the attacker to maintain a database of package versions and file sizes, for all repositories that victims maybe using, including arbitrary PPAs, rather than just looking for package names and versions in the URLs.
But also, while it's true that "other things use https" isn't necessarily a good justification for apt repos to follow suit, I do think it's past time that we completely stop using plaintext transport protocols for anything. Even when you're using http to download signed things (like software packages, or PGP keys from key servers), transport encryption makes network attacks, both passive and active, much harder and makes users safer.
[1] https:/ /github. com/thetorproje ct/ooni- probe