When Arch Linux reports that a PGP signature could not be verified, the issue typically stems from an outdated keyring, missing signing keys, or a corrupted local database. Resolving this requires updating the pacman keyring and refreshing the trusted keys to ensure package authenticity.
Understanding the Error Context
The error message one PGP signature could not be verified is a critical security warning issued by Pacman during package installation or system updates. It indicates that the digital signature attached to a package does not match any of the trusted public keys currently stored in your local keyring. This mismatch prevents Pacman from confirming the integrity and origin of the software, thereby blocking the operation to protect your system from potentially tampered files.
This problem frequently occurs after a fresh installation, when switching between different branches (such as stable vs. testing), or when the system has been offline for an extended period without syncing its cryptographic credentials. Unlike simple network errors, this is a trust issue. Your system knows how to verify signatures, but it lacks the specific public key required to validate the new or updated package.
Initial Diagnostic Steps
Before attempting fixes, it is crucial to identify whether the issue is isolated to a single package or affects the entire repository synchronization. If you are running sudo pacman -Syu and the error appears immediately during the download phase, check your internet connection first. However, if downloads complete successfully and the error triggers at the verification stage, the problem lies within your local GPG configuration.
You can inspect the current state of your keyring by listing the keys. Run the following command to see which keys are present and their status:
pacman-key --list-keysIf the output is empty or shows only a few generic keys, your keyring is likely incomplete. For beginners, it is also helpful to check if you have recently modified the /etc/pacman.conf file. Uncommenting repositories like [community] or [archlinuxfr] without having their corresponding keys imported will trigger this exact error. Ensure that any enabled repositories are supported by valid GPG keys.
Reinitializing the Pacman Keyring
The most reliable solution for persistent signature errors is to reinitialize the Pacman keyring. This process clears out potentially corrupted or expired keys and generates a new master key pair. Proceed with caution, as this step requires administrative privileges and may temporarily disable package verification until the keys are refreshed.
- Backup existing keys: Although rare, backing up ensures you can restore trust relationships if needed. Move the current keyring directory to a safe location:
sudo mv /etc/pacman.d/gnupg /etc/pacman.d/gnupg.bak - Initialize the new keyring: Remove the old directory and initialize a fresh one using Pacman's built-in tool:
This command generates a new DSA and Elgamal key pair. You might see a warning about entropy; on modern systems, this is usually harmless.sudo pacman-key --init - Load the default keys: Load the official Arch Linux packager keys into the new keyring:
If you use third-party repositories, such as those from AUR helpers or custom PPAs, you should populate them here as well. For example, to include the community repository keys, you might need to add specific flags depending on your setup.sudo pacman-key --populate archlinux
After completing these steps, your local environment should recognize the standard Arch Linux signatures. If you still encounter issues with specific external repositories, refer to our guide on Enabling GPG Keyring for External GPG Key IDs in Tech Support to handle non-standard keys correctly.
Refreshing Trusted Keys
Once the keyring is initialized, you must refresh the list of trusted keys from the remote servers. This ensures that your local copy matches the current state of the Arch Linux infrastructure, including any recent key rotations.
sudo pacman-key --refresh-keysThis command contacts the key servers specified in /etc/pacman.d/gnupg/pubring.kbx. It may take several minutes depending on your network speed. During this process, you might see warnings about keys being revoked or expired; this is normal behavior as the server updates its trust database. After the refresh completes, attempt your update again with sudo pacman -Syu.
If the error persists despite a successful refresh, consider checking for local clock skew. GPG signatures are time-sensitive; if your system date is significantly incorrect, signature validation will fail. Verify your time settings with timedatectl status and synchronize them using NTP if necessary.
Handling Specific Repository Errors
Sometimes the error is tied to a specific repository rather than the core system. If you have enabled the [multilib] or [community] repositories, ensure they are correctly configured. In some cases, manually importing a specific key for a problematic package can resolve the issue without resetting the entire keyring.
Identify the key ID from the error message (it usually looks like ABCDEF1234567890). Then, fetch and sign that specific key:
sudo pacman-key --recv-keys ABCDEF1234567890
sudo pacman-key --lsign-key ABCDEF1234567890The --recv-keys flag downloads the public key, while --lsign-key adds your local trust to it, allowing Pacman to accept packages signed by that key. This method is less disruptive than a full reinitialization and is preferred for targeted fixes.
Frequently Asked Questions
Why does this happen after a fresh install?
A fresh install starts with an empty or minimal keyring. Without running pacman-key --populate, the system lacks the authority to verify any downloaded packages, triggering immediate signature errors upon first update.
Can I ignore the signature error to force installation?
No, ignoring signature verification compromises system security. While --force exists in some contexts, bypassing GPG checks allows potentially malicious or corrupted code to execute, which defeats the purpose of package management integrity.
What if my system clock is wrong?
GPG validates timestamps strictly. If your hardware clock drifts significantly from UTC, signatures appear expired or not yet valid. Use chronyd or systemd-timesyncd to correct the time before retrying key operations.
How do I fix errors related to AUR packages?
AUR packages often require manual key imports. Ensure you have the maintainer's key in your keyring using pacman-key --recv-keys. For automated helpers, consult documentation on configuring trusted users to avoid repeated prompts.
Is it safe to delete the gnupg directory?
It is safe if you follow up with pacman-key --init and --populate. Deleting the directory removes all trust data, so you must rebuild the trust chain immediately to restore package verification capabilities.