I agree that an existing TLS implementation should be used. Is there a specific objection to curl, or it is just an issue of more dependencies? Maybe make apt "Recommends: apt-transport-https"? Or I was also thinking it would be part of a standard full install, like in the GNOME, XFCE, etc meta packages. I also think it is important that apt support HTTPS by default. HTTPS isn't a great protocol, but it is still better than nothing. There are legitimate concerns that can be helped by using apt with HTTPS, and there are at least 10 official mirrors that already support proper HTTPS. The integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. Here is how I break it down: 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for the attacker to do #2, #3, and #4. For example, if you use HTTPS to mirrors.kernel.org, everything has to be blocked to block Debian repos and packages. There was a whole discussion of this topic here: https://lists.debian.org/debian-security/2014/07/msg00002.html
Attachment:
signature.asc
Description: OpenPGP digital signature