AWS Security ChangesHomeSearch

AWS linux high security documentation change

Service: linux · 2026-06-22 · Security-related high

File: linux/al2023/ug/repo-metadata-signing.md

Summary

Expanded documentation on repository metadata signing, including new sections on automation usage, command behavior, detection of skipped repositories, and pinned version requirements. Added detailed explanations of security implications and automation guidance.

Security assessment

The changes explicitly address security vulnerabilities by documenting how unsigned metadata could allow compromised mirrors to hide/block security updates. It provides concrete mitigation steps (enabling repo_gpgcheck) and warns about risks in automation (missing security updates due to skipped repositories).

Diff

diff --git a/linux/al2023/ug/repo-metadata-signing.md b/linux/al2023/ug/repo-metadata-signing.md
index d53bef868..089b33559 100644
--- a//linux/al2023/ug/repo-metadata-signing.md
+++ b//linux/al2023/ug/repo-metadata-signing.md
@@ -7 +7 @@
-How repository metadata signing worksDifference between gpgcheck and repo_gpgcheckEnabling repository metadata verificationVerifying that repository metadata signing is workingGPG public keys for AL2023 repositories
+How repository metadata signing worksDifference between gpgcheck and repo_gpgcheckEnabling repository metadata verificationVerifying that repository metadata signing is workingUse repository metadata verification in automationCommands that refresh repository metadataDetect a skipped repositoryPinned versionsGPG public keys for AL2023 repositories
@@ -14,0 +15,2 @@ This signing is in addition to the existing RPM package signing (`gpgcheck`), wh
+Package signing protects each package. The metadata index that lists those packages is otherwise trusted based only on TLS and checksums. Without a signature on the index, a compromised mirror or transport path could serve modified metadata that hides or blocks security updates. Repository metadata signing closes this gap and does not depend on mirror or transport trust.
+
@@ -21 +23,3 @@ When you enable `repo_gpgcheck` in your repository configuration, DNF verifies t
-The first time DNF verifies a repository's metadata, it prompts you to import that repository's signing key into a per-repository keyring. This prompt defaults to `No`. If you decline it, or if no one can answer it (for example, an unattended run without the `-y` option), DNF skips the repository. For more information about `repo_gpgcheck`, see the [DNF Configuration Reference](https://dnf.readthedocs.io/en/latest/conf_ref.html).
+The first time DNF verifies a repository's metadata, it prompts you to import that repository's signing key into a per-repository keyring. This prompt defaults to `No`. If you decline it, DNF skips the repository. For more information about `repo_gpgcheck`, see the [DNF Configuration Reference](https://dnf.readthedocs.io/en/latest/conf_ref.html).
+
+This is the same key already used for package verification, but DNF stores it in a separate keyring for metadata checks. You are prompted to confirm it even though the key is already on disk. This is expected DNF behavior.
@@ -43 +47 @@ Setting | What it verifies | Default in AL2023
-We recommend that you enable both `gpgcheck` and `repo_gpgcheck`. This ensures that both the repository metadata and the individual packages are verified before use.
+We recommend that you enable both `gpgcheck` and `repo_gpgcheck`, after you confirm that your automation is ready. This verifies both the repository metadata and the individual packages before use. Before you enable `repo_gpgcheck`, see Use repository metadata verification in automation.
@@ -51 +55 @@ You can enable repository metadata verification for individual repositories by u
-Repository metadata signature verification is not enabled by default.
+Repository metadata signature verification is not enabled by default. It stays disabled until you change it. Before you enable it, confirm that every unattended DNF command in your automation passes the `-y` option. For more information, see Use repository metadata verification in automation.
@@ -64,0 +69,8 @@ The AL2023 repository configuration files in `/etc/yum.repos.d/` set `repo_gpgch
+### Disable repository metadata verification
+
+To return to the previous behavior, set `repo_gpgcheck=0` in the repository configuration file. The next metadata refresh succeeds without verification.
+    
+    
+    [ec2-user ~]$ sudo sed -i 's/^repo_gpgcheck=1/repo_gpgcheck=0/' /etc/yum.repos.d/amazonlinux.repo
+    [ec2-user ~]$ sudo dnf -y makecache
+
@@ -85 +97,104 @@ The first time DNF verifies the metadata for a repository, it prompts you to imp
-The import prompt defaults to `No`. If you decline it, DNF skips the repository and reports `Ignoring repositories` in the output.
+The import prompt defaults to `No`. If you decline it, DNF skips the repository and reports `Ignoring repositories` in the output. If verification fails, DNF reports a GPG signature error and does not create the cache.
+
+For unattended runs, see Use repository metadata verification in automation.
+
+## Use repository metadata verification in automation
+
+###### Note
+
+The key import prompt defaults to `No`. An unattended DNF run cannot answer the prompt, so it declines the import and skips the repository. Because AL2023 sets `skip_if_unavailable=True`, the command still exits with status `0`. As a result, the automation reports success while the host receives no packages or updates. The sign of this is `Ignoring repositories` in the output.
+
+To prevent this, pass the `-y` option to every unattended DNF command that refreshes metadata, including continuous integration jobs, image and container builds, `cloud-init`, configuration management, and cron jobs.
+    
+    
+    [ec2-user ~]$ sudo dnf -y makecache
+    [ec2-user ~]$ sudo dnf -y check-update
+    [ec2-user ~]$ sudo dnf -y upgrade
+
+Commands that refresh metadata need `-y`. Commands that read only the local cache or the local RPM database, or that use the `-C` option, do not refresh metadata and do not prompt. For the full list, see Commands that refresh repository metadata.
+
+Keep `-y` in your automation permanently. The key is imported once per repository URL, not once per host. AL2023 builds each repository URL from the locked version (`releasever`) and the AWS Region, so an OS version upgrade or a Region change resolves to a new URL and prompts again. The signing key does not change; only its keyring location does. Do not pre-seed or pre-bake the key as a one-time fix, because the next version upgrade or Region uses a new keyring and prompts again.
+
+Running `dnf clean all` clears cached metadata but does not remove the imported key within the same version. It does not re-trigger the prompt.
+
+Container image builds need particular attention. Every `RUN dnf` step in an image build is unattended, and the keyring is part of the image filesystem, so it starts empty in every fresh image. The prompt appears during the build regardless of what your running hosts have already imported. Pass `-y` in image builds.
+
+###### Note
+
+If you drive DNF as a Python library (`import dnf`), the prompt does not apply. The library imports the key without prompting, so metadata loads without `-y`.
+
+## Commands that refresh repository metadata
+
+Any command that downloads or refreshes repository metadata triggers the key import and the prompt. Commands that read only the local cache or the local RPM database do not. Options change the result: for example, `-v` makes `repolist` fetch, `--installed` keeps `list` and `info` local, `-C` or `--cacheonly` avoids fetching, and `--refresh` forces it. When in doubt, pass `-y`.
+
+Command | Refreshes metadata  
+---|---  
+`dnf makecache`| Yes  
+`dnf check-update`| Yes  
+`dnf upgrade`, `dnf update`| Yes  
+`dnf upgrade-minimal`| Yes  
+`dnf distro-sync`| Yes  
+`dnf install`| Yes  
+`dnf reinstall`| Yes  
+`dnf downgrade`| Yes  
+`dnf autoremove`| Yes  
+`dnf swap`| Yes  
+`dnf list` (default or `--available`)| Yes  
+`dnf info` (default or `--available`)| Yes  
+`dnf search`| Yes  
+`dnf provides`| Yes  
+`dnf repoquery`| Yes  
+`dnf repoinfo`| Yes  
+`dnf deplist`| Yes  
+`dnf repository-packages`| Yes  
+`dnf updateinfo`| Yes  
+`dnf group` (list, info, install)| Yes  
+`dnf module` (list, info)| Yes  
+`dnf shell` (if its subcommands fetch)| Yes  
+`dnf builddep`| Yes  
+`dnf changelog`| Yes  
+`dnf debuginfo-install`| Yes  
+`dnf download`| Yes  
+`dnf repoclosure`| Yes  
+`dnf repograph`| Yes  
+`dnf reposync`| Yes  
+`dnf debug-dump`| Yes  
+`dnf repolist -v` (verbose)| Yes  
+`dnf repolist` (plain or `--all`)| No  
+`dnf list --installed`, `dnf info --installed`| No  
+`dnf remove`, `dnf erase`| No  
+`dnf mark`| No  
+`dnf history`| No  
+`dnf check`| No  
+`dnf clean`| No  
+`dnf config-manager`| No  
+`dnf needs-restarting`| No  
+`dnf alias`| No  
+`dnf help`| No  
+`dnf repomanage`| No  
+`dnf repodiff`| No (errors unless two repositories are named)  
+`dnf copr`| No  
+`dnf groups-manager`| No  
+`dnf playground`| No  
+`dnf debug-restore`| No (acts on a saved dump)  
+Any command with `-C` or `--cacheonly`| No  
+  
+A repository skipped this way is reported as `Ignoring repositories` in the output, but most of these commands still exit with status `0` because AL2023 sets `skip_if_unavailable=True`. Do not rely on the exit code alone. Pass `-y` so the key import succeeds.
+
+## Detect a skipped repository
+
+The exit code alone does not confirm that verification succeeded. A skipped repository exits `0`, and the signing key persists once any run imports it, so a later check can pass while an earlier step still fails. Use these two checks instead:
+
+  * Audit your automation. Confirm that every metadata-fetching DNF command passes `-y`. This is what keeps you working on the next new repository URL.
+
+  * Check the output for `Ignoring repositories`. The following command fails when the repository is skipped, which you can use to fail a pipeline:
+
+
+
+    
+    
+    [ec2-user ~]$ sudo dnf makecache 2>&1 | grep -q "Ignoring repositories" && { echo "repo skipped"; exit 1; }
+
+## Pinned versions
+
+If you pin `releasever` (with `--releasever`, `/etc/dnf/vars/releasever`, or `dnf.conf`) to a version released before `2023.11.20260406`, that version has no signature file, and `repo_gpgcheck=1` fails to refresh the repository:
@@ -87 +201,0 @@ The import prompt defaults to `No`. If you decline it, DNF skips the repository
-###### Important
@@ -89 +203,2 @@ The import prompt defaults to `No`. If you decline it, DNF skips the repository
-The signing key is imported into a per-repository keyring that is keyed to the resolved repository URL. The import prompt appears again whenever that URL changes, such as after a version or Region change. For unattended runs such as cron jobs, container builds, and automation, pass the `-y` option to every DNF command that refreshes metadata, so the key is imported without a prompt. Without `-y`, the prompt defaults to `No`, DNF skips the repository, and the command can still exit with status `0`.
+    Error: Failed to download metadata for repo 'amazonlinux':
+    GPG verification is enabled, but GPG signature is not available...
@@ -91 +206 @@ The signing key is imported into a per-repository keyring that is keyed to the r
-If the signature verification fails, DNF displays an error message indicating a GPG signature verification failure and metadata cache creation fails.
+A pinned version does not receive updates beyond that version. If you pin, pin to version `2023.11.20260406` or later, or set `repo_gpgcheck=0`.