On Mon, 5 Apr 2021 at 13:05, Warren Young <warren at etr-usa.com> wrote: > On Apr 5, 2021, at 8:32 AM, Johnny Hughes <johnny at centos.org> wrote: > > > > wrt private keys .. we don't want any to live on machines we > > don't physically own. > > Yeah, I get that. > > What I don’t get is why, if DNF goes to http://foo.centos.org to pull > metadata, and it tells DNF to go to https://bar.qux.example.edu to > download the packages specified by that metadata, why must there be any > private keys for *.centos.org involved on example.edu’s servers? > > I don't think they do require it unless that node is supposed to look like a part of mirror.centos.org. The issue is that various tools fail when a mirrorlist sends them data which is not the same as 'requested'. So if you send over a http link and get an https, the tool may crash or try to talk HTTP to the TLS port etc. ``` $ curl 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=BaseOS' http://mirror.us.oneandone.net/linux/distributions/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.cs.vt.edu/pub/CentOS/8.3.2011/BaseOS/x86_64/os/ http://distro.ibiblio.org/centos/8.3.2011/BaseOS/x86_64/os/ http://ftpmirror.your.org/pub/centos/8.3.2011/BaseOS/x86_64/os/ http://mirrors.rit.edu/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.atl.genesisadaptive.com/centos/8.3.2011/BaseOS/x86_64/os/ http://atl.mirrors.clouvider.net/CentOS/8.3.2011/BaseOS/x86_64/os/ http://repos-va.psychz.net/centos/8.3.2011/BaseOS/x86_64/os/ http://centos-distro.cavecreek.net/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.vtti.vt.edu/centos/8.3.2011/BaseOS/x86_64/os/ ``` A metalink system provides different data which would allow for these 'transfers' but it has other problems which are mitigated with TLS connections ``` <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Mon, 05 Apr 2021 17:20:24 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <files> <file name="repomd.xml"> <mm0:timestamp>1603150039</mm0:timestamp> <size>6282</size> <verification> <hash type="md5">7de20cbe8e7ef87b4fc1b35191277ab4</hash> <hash type="sha1">7d0c65c0daf1677eda2152e25e39a3dc4f3be027</hash> <hash type="sha256">7a75be2ebd56e44c9d33252a12158c8b7079331e9c73aa62c609414299dabf06</hash> <hash type="sha512">dfcc30a274b140d3ff65c3b3c9987a7c057a30e89880b13472f61be5fdd8829761653e11309d25680dc89d1af91d015ea0ca6992bbabec60d8b472f3e81ebba2</hash> </verification> <resources maxconnections="1"> <url protocol="http" type="http" location="US" preference="100"> http://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml </url> <url protocol="rsync" type="rsync" location="US" preference="100">rsync:// download-ib01.fedoraproject.org/fedora-enchilada/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml </url> <url protocol="https" type="https" location="US" preference="100"> https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml </url> </resources> </file> </files> </metalink> ``` In this way the tool can know and choose the version of TLS or download protocol (rsync) which it can deal with. I don't present this as a better way, just a different way. Both systems make different security and availability choices to meet different requirements. [The Fedora system is known to be fragile in TLS bringup during the thundering bison rush of several million EPEL systems updating caches at 04:00 while the CentOS system doesn't have this issue.] > Surely the sysadmin of bar.qux.example.edu obtains a TLS key pair from > some trusted CA that certifies that bar.qux.example.edu is valid > according to the worldwide TLS public PKI. > > If we’re talking about package signing keys, surely that all happens on > centos.org servers, and the resulting RPM packages are distributed as-is, > not re-signed on each mirror server. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen.