RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1237057 - GPG key retrieval failed when EPEL is enabled on host
Summary: GPG key retrieval failed when EPEL is enabled on host
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-30 09:53 UTC by Michal Fojtik
Modified: 2020-06-09 21:10 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-09 21:10:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Michal Fojtik 2015-06-30 09:53:56 UTC 
Description of problem:

This might be a tricky bug (and maybe a feature) but I discovered today that if you have EPEL (or any other repo that contains GPG keys) then installing a package inside container from that repo will fail as the yum will fail to locate the GPG key to import.


Actual results:

Downloading packages:
warning: /var/cache/yum/x86_64/7Server/epel/packages/nss_wrapper-1.0.3-1.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Public key for nss_wrapper-1.0.3-1.el7.x86_64.rpm is not installed
--------------------------------------------------------------------------------
Total                                               14 MB/s |  17 MB  00:01     
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

GPG key retrieval failed: [Errno 14] curl#37 - "Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7"

NOTE that I **don't** have EPEL repo RPM installed in container, but it is installed on host.


Expected results:

I think the simple solution would be to also mount the /etc/pki/rpm-gpg into /var/run/secrets and guide users to import the keys from there.
Comment 2 Daniel Walsh 2015-07-15 20:23:25 UTC 
Is this for docker build?
Comment 3 Daniel Walsh 2015-07-15 20:25:06 UTC 
Can't you just download the keys into the container?  I think we would want to make the same symlink magic we do to make this work properly.
Comment 4 Daniel Walsh 2015-08-21 03:40:22 UTC 
Michal can you answer the questions ^^
Comment 5 Daniel Walsh 2015-08-21 03:40:41 UTC 
Michal can you answer the questions ^^
Comment 6 Michal Fojtik 2015-08-24 11:06:22 UTC 
Daniel: Yes, I can but I would expect this to work smoothly when using repos from my host machine.
Comment 7 Daniel Walsh 2015-09-28 18:01:11 UTC 
Daniel Riek what do you think the correct solution is?
Comment 8 Subhendu Ghosh 2015-10-28 14:18:50 UTC 
I think the solution makes sense - mount the gpg keys directory in addition to the client certs directory to complete the secrets requirements.

The yum install inside the container would also have to "accept/insert" the GPG key on first run. Is that going to be a problem?
Comment 9 Daniel Walsh 2015-10-29 17:49:30 UTC 
Then the goal would be to 

mount /etc/pki/rpm-gpg /run/secrets/rpm-gpg

What is the location of the Certs dir?  Will this work if I am on a RHEL7 box and have a RHEL6 image? RHEL6 EPEL?
Comment 10 Daniel Walsh 2016-01-06 19:51:24 UTC 
If you just add a link 

ls -l /etc/pki/rpm-gpg /usr/share/rhel/secrets/rpm-gpg

You will get the content into the container.
Comment 11 Daniel Walsh 2016-01-06 19:51:43 UTC 
Under /run/secrets
Comment 12 Pavel Raiskup 2016-01-06 20:30:24 UTC 
Something is wrong here, or?  Having EPEL-7 propagated into Dockerfile does
seem to be security problem.

It is like we've done mock build for *pure* RHEL-7 chroot but the EPEL-7 was
available inside.
Comment 13 Pavel Raiskup 2016-01-06 20:33:58 UTC 
I mean, yes - host need to properly define right yum repos  and related
GPG keys, but inheriting *all* the repos from host sounds wrong.
Comment 14 Colin Walters 2016-01-06 20:50:57 UTC 
I want more precise control over the repos that the secrets patch/subman is injecting from the host, as well as the ability to have yum repos defined on the host that are *only* injected for containers.

At the moment, one can work around all of this by basically disabling the secrets patch inside each container, create a bind mount -v /etc/pkgrepos.d:/etc/pkgrepos.d, then inside the container, rm /etc/yum.repos.d/redhat.repo && cp -a /etc/pkgrepos.d/* /etc/yum.repos.d etc.
Comment 15 Bin Won 2016-02-24 01:18:57 UTC 
Solution that worked for me (CentOS 7):
1. Delete all epel***.repo files inside /etc/yum.repo.d/ folder
2. Reinstall these repo files : yum install epel-release
Comment 16 jinqlu 2016-04-06 00:19:08 UTC 
My case: Running Red Hat Openstack 7, it has the same error, the reason is because the install is looking for "/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL", but the file there is "/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7", so the esay fix is to copy the file "RPM-GPG-KEY-EPEL-7" as "RPM-GPG-KEY-EPEL" in same dir, re-run install, everything is fine.

$ sudo yum install -y python-rdomanager-oscplugin

warning: /var/cache/yum/x86_64/7Server/epel/packages/fio-2.2.8-2.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL


GPG key retrieval failed: [Errno 14] curl#37 - "Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL"

[stack@osp7_director ~]$ ls -l /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
ls: cannot access /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL: No such file or directory

[stack@lab31_osp7_director ~]$ ls -l /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL*
-rw-r--r--. 1 root root 1662 Nov 25  2014 /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7


$ sudo cp /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

$ sudo yum install -y python-rdomanager-oscplugin

...Complete!
Comment 18 Tom Sweeney 2020-06-09 21:10:06 UTC 
We have no plans to ship another version of Docker at this time. RHEL7 is in final support stages where only security fixes will get released.  Customers should move to use Podman which is available starting in RHEL 7.6.
Note You need to log in before you can comment on or make changes to this bug.