Not done as per Egypt and UAE HTTP Repository Manipulation/Poison · Issue #4415 · QubesOS/qubes-issues · GitHub
Not sure it was clever by me to mention public perception.
If it’s just public perception it’s best to be quiet about it. No one going to dig deep and few going to complain.
https is going to reflect badly due to amazon AWS as per:
But it’s not a popularity contest.
I am not totally convinced that SSL makes things more secure either.
Note: talking about security, not about privacy.
-
gpg verification: considered strong and not broken
-
https:
- we don’t trust as per Whonix and Tor Limitations but somehow on subject of apt sources we suddenly trust it
- the many SSL security issues found in webservers and browsers over the recent years - how likely that APT isn’t scrutinized as much and has vulnerabilities related to SSL?
- curl - CVEs
- [ Vulnerabilities ] - /news/vulnerabilities.html
-
attack surface increased to both, the SSL verification code as well as the gpg verification code
- stacking up code can lead to a bigger code base that has to be trusted
- how could the gpg verification code be even attacked if SSL prevents any MITM from delivering malicious files?
- Well, the files are provided by mirrors which are considered untrusted. Otherwise if SSL was so great we could in theory rely on SSL only and disable gpg verification.
But it always seems a good idea to combine levels of protections, and well, it’s what everyone is doing.
Do you mean https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build or something else?
https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build is non-trivial but solvable somehow.