On Mon, 5 Apr 2021 at 13:05, Warren Young warren@etr-usa.com wrote:
On Apr 5, 2021, at 8:32 AM, Johnny Hughes johnny@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/x8... 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:timestamp1603150039</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/Everythi... </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/Everyth... </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@centos.org https://lists.centos.org/mailman/listinfo/centos