On Mon, 5 Apr 2021 at 13:05, Warren Young <warren@xxxxxxxxxxx> wrote:
> On Apr 5, 2021, at 8:32 AM, Johnny Hughes <johnny@xxxxxxxxxx> 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@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
--
Stephen J Smoogen.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
