## TL;DR
The package is signed, but its signing key is not in the host RPM keyring. Import the vendor official key with rpm --import using the key URL from the vendor repo file (the gpgkey line), confirm the fingerprint against the vendor site, and rerun the update. In automation, pre-import the key in the image or config management instead of disabling gpgcheck.

```text
yum update failed error public key for package is not installed
```

## Use this when
- yum update stops with Public key for [package] is not installed.
- The failing package comes from a newly added third-party repo.
- Non-interactive patching (cron or agent runs) fails where interactive yum once prompted.

## Not for this skill when
- The package is unsigned and locally built. Sign it or install it as a deliberate local exception, not a repo key problem.
- The repo metadata itself fails signature checks. That is repomd verification, a different layer.

## Steps
1. Note the package and its repo from the yum output. Verify: the source repo of the failing package is identified
2. Open that repo file in yum.repos.d and read its gpgkey URL. Verify: the key URL belongs to the vendor official domain
3. Import the key with rpm --import using that URL, or answer the interactive import prompt after checking the fingerprint. Verify: the import completes without error
4. List imported keys and match the fingerprint to the vendor published value. Verify: the fingerprint matches exactly
5. Rerun yum update. Verify: the transaction proceeds past signature checking

## Variant phrasings
### rpm gpg key not installed import key fix
The action-first phrasing.
### dnf public key not installed automation fails
The non-interactive variant phrasing.
### epel package public key not installed
The common EPEL-specific phrasing.

Compatibility: Compatibility: RHEL, CentOS, AlmaLinux, and Rocky with yum 4 / dnf; repo files under yum.repos.d.

## Why it happens
RPM verifies package signatures against keys stored in the RPM database. An interactive yum session offers to import a repo key on first use, so the problem often stays hidden until the first unattended run, when there is nobody to answer the prompt and the transaction aborts. Key rotation by a vendor produces the same failure on a repo that worked for years.

## Edge cases / pitfalls
- Setting gpgcheck to 0 silences the error and the protection; treat any host found that way as a finding to fix, not a solution.
- Repo files fetched from the internet can point gpgkey anywhere; only import keys whose fingerprints you verified from the vendor.
- In images, import keys at build time so first boot patching is fully unattended.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tVhcvrby2ZoYoqFIVEikjg