EPEL: Security Profiles in EL7 can cause problems with outside repositories

Currently, if you are installing CentOS 7 or Red Hat Enterprise Linux and use a security profile, you will have problems with 3rd party repositories. The errors can seem rather obtuse, and it usually gets diagnosed as "EPEL is down" or some similar problem. The test will look something like:

epel/x86_64/metalink                                                                                                                                  |  17 kB  00:00:00     
https://mirrors.rit.edu/fedora/epel/7/x86_64/repodata/repomd.xml.asc: [Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below wiki article 


If above article doesn't help to resolve this issue please use https://bugs.centos.org/.

http://mirror.nodesdirect.com/epel/7/x86_64/repodata/repomd.xml.asc: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.
http://mirror.us.leaseweb.net/epel/7/x86_64/repodata/repomd.xml.asc: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.
The key part to look at is the request for repomd.xml.asc. That is where yum is asking for the gpg signed repository xml metadata. The Fedora Project does not currently sign its data for various reasons. This means that the yum will not see the epel archive as active and refuse to show packages.

There are two fixes that are currently available:

  1. reposync the repository and sign that repository with keys that you have accepted. This is what most sites which require a security profile are going to need to do. It means that there is a process and control and signoff which would meet that sites security plan.
  2. Turn off the checking of repository signatures for the EPEL repository.
    name=Extra Packages for Enterprise Linux 7 - $basearch
    WARNING: Doing this on many systems without getting an allowed exception will cause audit problems. This is the primary reason that EPEL does not come with this automatically. It MUST be a conscious decision of the installation systems administration to turn it off.
And yes, a third option would be to have the metadata signed. I am not an authority on why the data is not currently done so and do not like arm-chair quarterbacking people who have to deal with the build system. 

No comments: