Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Repository metadata signing in AL2027

AL2027 repositories include cryptographic signatures for repository metadata. Each repository's repomd.xml file comes with a detached GPG signature file (repomd.xml.asc). DNF can use this signature to verify the authenticity and integrity of the repository metadata before downloading packages. AL2023 added this capability with release 2023.11.20260406; AL2027 has it from the start.

Metadata signing is in addition to RPM package signing (gpgcheck), which verifies individual packages. Without a signature on the metadata index, that index is trusted based only on TLS and checksums, so a compromised mirror or transport path could serve modified metadata that hides or blocks security updates. Repository metadata signing closes this gap.

How repository metadata signing works

When you enable repo_gpgcheck in a repository configuration, DNF verifies the repomd.xml.asc signature against the repository's GPG public key before it uses the metadata. If verification fails, DNF does not use the metadata. Because AL2027 repositories set skip_if_unavailable=1, DNF then skips the repository and continues. For how to catch this in automation, see Detect a skipped repository.

The first time DNF verifies a repository's metadata, it prompts you to import the signing key into a separate keyring used for metadata checks. The prompt defaults to No, and declining it skips the repository.

The following AL2027 repositories include signed metadata:

Difference between gpgcheck and repo_gpgcheck

We recommend enabling both settings after you confirm that your automation is ready. Before you enable repo_gpgcheck, see Use repository metadata verification in automation.

Enabling repository metadata verification

Enable for a specific repository

The AL2027 repository configuration in /etc/yum.repos.d/amazonlinux.repo sets repo_gpgcheck=0 by default. To enable metadata verification, change the value to 1 for each repository section:

[amazonlinux]
name=Amazon Linux 2027 repository
...
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2027

The same key verifies both packages and repository metadata. The system-release package installs it at /etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2027.

Disable repository metadata verification

To return to the default behavior, set repo_gpgcheck=0 again. The next metadata refresh succeeds without verification:

sudo sed -i 's/^repo_gpgcheck=1/repo_gpgcheck=0/' /etc/yum.repos.d/amazonlinux.repo
sudo dnf -y makecache

Verifying that repository metadata signing is working

After enabling repo_gpgcheck=1, clear the DNF cache and refresh the metadata:

sudo dnf clean metadata
sudo dnf -y makecache

The first time DNF verifies a repository's metadata, it imports that repository's signing key into a separate keyring used for metadata checks, and asks for confirmation. This is the same key already used for package verification; the confirmation for the separate keyring is expected behavior. With -y, the key is imported and the cache is created without errors:

Updating and loading repositories:
 Amazon Linux 2027 repository           100% |  22.3 KiB/s |   4.5 KiB |  00m00s
>>> repomd.xml GPG signature verification error: Signing key not found
Importing OpenPGP key 0xB1E92E3D:
 UserID     : "Amazon Linux amazon-linux@amazon.com"
 Fingerprint: 37CE 7C38 33E5 A33C 4A1E 4B0D 5408 EAA4 B1E9 2E3D
 From       : file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2027
The key was successfully imported.
 Amazon Linux 2027 repository           100% |  10.8 MiB/s |   2.4 MiB |  00m00s
Repositories loaded.
Metadata cache created.

The Signing key not found line before the import is expected on the first run: verification is attempted, the key is imported, and verification then succeeds. If verification fails after the key is imported, DNF reports the repomd.xml GPG signature verification error and the metadata is not used.

Use repository metadata verification in automation

The key import prompt defaults to No. An unattended DNF run cannot answer the prompt, so it declines the import and metadata verification fails for the repository. The command can still exit with status 0, so do not rely on the exit code alone. For how to catch this, see Detect a skipped repository.

To prevent this, pass the -y option to every unattended DNF command that refreshes metadata, including CI jobs, image and container builds, cloud-init, configuration management, and scheduled jobs.

Keep -y in your automation permanently. The key is imported once per repository URL, and AL2027 builds each repository URL from the locked release version, so moving to a different release version resolves to a new URL and prompts again. Container image builds need particular attention. The keyring is part of the image file system and starts empty in every fresh image, so every RUN dnf build step is a first-time import.

Commands that refresh repository metadata

Any command that downloads repository metadata triggers verification, and with it the one-time key import. Commands that read only the local cache or the local RPM database do not. The table covers the commands that dnf5 --help lists on AL2027, including the preinstalled plugins and the dnf5-plugins package. Each behavior was measured against a cleaned cache. Command aliases, such as dnf update or dnf rq, behave like the command they map to. Options change the result: --installed keeps list and info local, and -C (--cacheonly) prevents any fetch. When in doubt, pass -y.

Detect a skipped repository

The exit code alone does not confirm that verification succeeded. AL2027 repositories set skip_if_unavailable=1, so when metadata verification fails, DNF prints the error, skips the repository, and still exits with 0:

sudo dnf upgrade

Updating and loading repositories:
 Amazon Linux 2027 repository           100% |  46.8 KiB/s |   4.5 KiB |  00m00s
>>> repomd.xml GPG signature verification error: Signing key not found
Repositories loaded.
Nothing to do.

On a system with pending updates, this looks like success. Use these two checks instead:

if sudo dnf makecache 2>&1 | grep -q "GPG signature verification error"; then
  echo "repo skipped"
  exit 1
fi

After the key is imported, a healthy refresh prints no verification error, and the check passes.

Pinned versions

All AL2027 releases carry signed repository metadata, so pinning releasever (with --releasever or /etc/dnf/vars/releasever) works with repo_gpgcheck=1. During the preview period, old preview releases can be removed from the repositories. A pinned version does not receive updates beyond that version, and a removed version stops resolving. Pin to a current release listed in the AL2027 Release Notes.

GPG public keys for AL2027 repositories

The GPG public key used for repository metadata verification is installed to /etc/pki/rpm-gpg/ by the system-release package. The following table lists the key used by each repository.