On 2/8/21 10:09 PM, Chris Drake wrote: > 1. Your info page here: > links to an insecure download resource: > http://mirror.centos.org/centos/8-stream/ > ... > take a look at the number of warnings related to unsigned code > ... > we really need to be able to download binaries ... preferably all with > working signatures, but that's a whole other problem, so TLS distro > endpoints is at least an interim mitigation Generally speaking, TLS provides three things: privacy, authentication, and integrity. For package installation, privacy isn't an essential component. There's nothing secret in the package contents. They're all publicly available. TLS can authenticate the server, but it would fail to authenticate the origin of the software itself. In short, it would authenticate the wrong thing. You'd get integrity. Nothing wrong with that, per se. The package distribution network as it is does not provide privacy, as it is not an essential requirement. It does, however, provide authentication and integrity by signing the package files themselves. This has the advantage that the origin (CentOS) is authenticated properly, as well as remaining friendly to caching proxy servers. Running the package distribution network over https would lose the advantage of proxy friendliness, increase the costs placed on the mirror sites (you cited LetsEncrypt certificates, but are not considering the overhead of encrypting gigabit or 10-gigabit data channels), and duplicate characteristics already provided by signing the packages. Additionally, I feel like insisting on HTTPS for the channel overlooks one of the most important considerations in the overall design of the package distribution network, and that is that the mirrors aren't actually trusted systems. CentOS does not control them, and doesn't audit them for correctness. If a mirror is compromised, and a bad package is served from one, HTTPS would do absolutely nothing to protect end users. HTTPS would imply trust where none should be inferred. The system must work over untrusted channels, which makes HTTPS an unnecessary and costly overhead. I'm a little confused at your last point about working signatures. You seem to understand that TLS wouldn't be adequate to the purpose of software signing, and it sounds like you're suggesting that the software isn't signed now.