> From what I can tell, the repo metadata is hashed by sha256 but that > is not the same a cryptographically signed. > > What are you finding is performing a verification of the repomd.xml > against the CentOS public key before parsing it with libxml2? There are two kinds of signatures: gpg signatures on rpms (option gpgcheck) == verify source and integrity of the RPM gpg signatures on yum metadata (option repo_gpgcheck) == verifies the metadata and thus what you see in the repository. This verifies that nobody tampered with what has been published and thus the list of packages you get is what was published. while the first is enabled (https://git.centos.org/rpms/centos-release/blob/c8s/f/SOURCES/CentOS-Base.repo or https://git.centos.org/rpms/centos-repos/blob/c8/f/SOURCES/CentOS-Linux-BaseOS.repo) the second is not. It would also be great to do the second by default, especially since the mirrorlist keeps being pure http. More on background: https://blog.packagecloud.io/eng/2014/11/24/howto-gpg-sign-verify-rpm-packages-yum-repositories/ What is important with http as a pure transport for mirrors is what Julien pointed out: Even if you have gpgcheck and repo_gpgcheck enabled and there is a 0day in libxml2 an active attacker can keep serving you the outdated repository information and you won't get any updates. But all seems fine, since you verify signature of both. If you don't verify metadata (as it is now) an active attacker can even serve you updated content for all the other packages except for libxml2 and while keeping you thinking that you have your system up2date (since it runs and installs updates) your system can be kept vulnerable. If the source from where you are fetching the content is using https and you are validating the certificate it is much harder (or nearly impossible) to deliver you an outdated (or tampered) view on the repository. Now what is the state of how you get your content using dnf: you fetch the mirrorlist curl "http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=centos-devel" => you get a list of mirrors with their own hostname and you fetch the current metadata from one of these mirrors. Since you are redirected to mirrors using their own hostname, they can likely use LE (or whatever they want) to get a certificate signed by a well known CA. And it looks like nearly all of the mirrors I get back do that: tldr; one does not answer on 443 and one has a certificate not signed by a well known CA. # curl -s "http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=centos-devel" | while read -r repo; do echo -n "${repo} "; curl -s -o /dev/null --connect-timeout 2 -I $(echo $repo | sed "s at http://@https://@") && echo OK || echo FAILED; done http://pkg.adfinis.com/centos/8-stream/AppStream/x86_64/os/ OK http://mirror.init7.net/centos/8-stream/AppStream/x86_64/os/ OK http://linuxsoft.cern.ch/centos/8-stream/AppStream/x86_64/os/ OK http://centos.mirror.net-d-sign.de/8-stream/AppStream/x86_64/os/ FAILED http://artfiles.org/centos.org/8-stream/AppStream/x86_64/os/ OK http://mirror.infonline.de/centos/8-stream/AppStream/x86_64/os/ OK http://mirror.netzwerge.de/centos/8-stream/AppStream/x86_64/os/ OK http://ftp.plusline.net/centos/8-stream/AppStream/x86_64/os/ OK http://ftp.rz.uni-frankfurt.de/pub/mirrors/centos/8-stream/AppStream/x86_64/os/ FAILED http://mirror.imt-systems.com/centos/8-stream/AppStream/x86_64/os/ OK So the hard thing is to get mirrorlist behind https and nagging the few mirrors not yet arrived in 2021 to enable proper https. Now if we look at what Fedora does (e.g. for EPEL): curl -s "https://mirrors.fedoraproject.org/metalink?repo=epel-source-8&arch=x86_64&infra=centos-devel" | grep protocol= | sed 's/.*protocol="\(.*\)" type=.*/\1/' | sort | uniq -c 64 http 36 https 50 rsync => there is a reasonable amount of https mirrors out there, but still quite a lot http - don't know how dnf selects them... Same picture for Fedora repos, since it's the same infra. Anyway how it could make work, so that folks could hop into a more secure delivery is: 1. serve mirrorlist under http (default as by now) & https (new!) 2. server mirrorlist as xml with more metadata per mirror (protocol & type) as for epel (new!) 3. make it possible that dnf can prefer/enable/disable protocols (new!) then with CentOS 9 Stream one could switch to 1. have mirrorlist by default over https (http variant still available) 2. enable repo_gpgcheck by default 3. let https be the preferred method for dnf (can be downgraded to http for folks behind ssl terminating proxies without local mirrors) However, I guess since things are intervened with Fedora and Fedora also has: 1. repo_gpgcheck not enabled by default :( 2. a mixed list of http, https and rsync mirrors 3. no way on dnf (afaik) to prefer https it's probably a good starting point over there. ~pete