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 1090682 - Base install of RHEL7 needs Red Hat GPG public key for yum gpg checking
Summary: Base install of RHEL7 needs Red Hat GPG public key for yum gpg checking
Keywords:
Status: CLOSED DUPLICATE of bug 998
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-23 23:31 UTC by Ryan J Nicholson
Modified: 2021-12-10 14:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-30 12:38:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ryan J Nicholson 2014-04-23 23:31:54 UTC 
Description of problem:

Unpacking RHEL isos and pointing to the repo with yum gives a "no public keys installed" message.

Version-Release number of selected component (if applicable):

RHEL7 RC

How reproducible:

If a .repo file in yum.repos.d is set up without gpgcheck=no (ie, the default of gpg checking enabled is active), the message always appears.

Steps to Reproduce:
1. Unpack RHEL7 RC .iso.
2. Point to the repo w/ /etc/yum.repos.d/rhel7.repo.
3. Any yum command will report no public keys installed.

Actual results:

The user is presented with instructions for installing a public key to verify signed RPM packages.

Expected results:

The Red Hat public key should be installed by default so this message is suppressed.

Additional info:

Since this is on a test system not registered under a support contract, maybe the Red Hat public key is installed as part of the registration process. But I think it probably still should be included in the base install to make GPG checking work out of the box.
Comment 2 David Cantrell 2014-04-30 12:38:59 UTC 
This is deliberate.  GPG keys are not present in the install environment and packages are installed without GPG key checking when using a supported install path.  GPG keys used to verify signed packages are installed on the target system (look in /etc/pki/rpm-gpg).  The GPG keys are delivered as part of the redhat-release package.

What you are describing though is outside of the normal installation environment.  If you are setting up the RHEL repos somewhere else, the GPG keys used to verify those packages are in the release tree at the top level.  You will need to provide those files to the receiving system in order to verify packages you install.

The core issue that I think you're getting at is the same as the discussion that has been going on in bug #998 for a long time.  It's a bootstrapping issue.  We cannot provide GPG keys on the install media in order to check signatures on packages because there's no way to trust those keys.  We have to provide the GPG keys externally and insist that users add them to their local RPM configuration before signature verification can work.  As stated above, this happens mostly for users when they follow a supported install path.  The only thing we don't do is automatically add the GPG keys to the RPM database.  The user is still prompted to verify that operation before it happens, but that occurs on the installed system.

*** This bug has been marked as a duplicate of bug 998 ***
Note You need to log in before you can comment on or make changes to this bug.