[CentOS] Can't upgrade sssd-*

Mon Apr 5 17:26:36 UTC 2021
Stephen John Smoogen <smooge at gmail.com>

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'

A metalink system provides different data which would allow for these
'transfers' but it has other problems which are mitigated with TLS

<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic"
pubdate="Mon, 05 Apr 2021 17:20:24 GMT" generator="mirrormanager"
  <file name="repomd.xml">
    <hash type="md5">7de20cbe8e7ef87b4fc1b35191277ab4</hash>
    <hash type="sha1">7d0c65c0daf1677eda2152e25e39a3dc4f3be027</hash>
   <resources maxconnections="1">
    <url protocol="http" type="http" location="US" preference="100">
    <url protocol="rsync" type="rsync" location="US"
    <url protocol="https" type="https" location="US" preference="100">

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.