pacman/Package signing

The SigLevel option in /etc/pacman.conf determines the level of trust required to install a package with pacman -S. For a detailed explanation of SigLevel, see pacman.conf(5) § PACKAGE AND DATABASE SIGNATURE CHECKING, and the file comments. One can set signature checking globally, or per repository. If SigLevel is set globally in the [options] section, all packages installed with pacman -S will require signing. With the setting from the default , any packages you build, and install with , will not need to be signed using makepkg.

For remote packages, the default configuration will only support the installation of packages signed by trusted keys:

/etc/pacman.conf

SigLevel = Required DatabaseOptional

is a default compiled-in pacman parameter. The default configuration is identical to using the global option of:

SigLevel = Required DatabaseOptional TrustedOnly

The above can be achieved too on a repository level further below in the configuration, e.g.:

[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

explicitly adds signature checking for the packages of the repository, but does not require the database to be signed. here would turn off a global Required for this repository.

To initialize the pacman keyring run:

# pacman-key --init

Initializing the keyring requires entropy. To generate entropy, move your mouse around, press random characters on the keyboard, or run some disk-based activity (for example in another console running or or ). If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.

The randomness created is used to initialize the keyring () and the GPG signing key of your system.

The initial setup of keys is achieved using:

# pacman-key --populate

Take time to verify the Master Signing Keys when prompted as these are used to co-sign (and therefore trust) all other packager's keys.

PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last sixteen digits of the fingerprint would be the 'long key ID').

The official developer and Trusted Users (TU) keys are signed by the master keys, so you do not need to use pacman-key to sign them yourself. Whenever pacman encounters a key it does not recognize, it will prompt you to download it from a keyserver configured in (or by using the option on the command line). Wikipedia maintains a list of keyservers.

Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.

This method can be utilized to add a key to the pacman keyring, or to enable signed unofficial user repositories.

First, get the key ID (keyid) from its owner. Then add it to the keyring using one of the two methods:

1. If the key is found on a keyserver, import it with:
2. If otherwise a link to a keyfile is provided, download it and then run:

It is recommended to verify the fingerprint, as with any master key or any other key you are going to sign:

$ pacman-key --finger keyid

Finally, you must locally sign the imported key:

# pacman-key --lsign-key keyid

You now trust this key to sign packages.

For debugging purposes, you can access pacman's keyring directly with gpg, e.g.:

# gpg --homedir /etc/pacman.d/gnupg --list-keys

Upgrading the system regularly via pacman#Upgrading packages prevents most signing errors. If delay is unavoidable and system upgrade gets delayed for an extended period, manually sync the package database and upgrade the package before system upgrade:

# pacman -Sy archlinux-keyring && pacman -Su

This command is not considered a partial upgrade since it syncs the package database and upgrades the keyring package first. Both must be processed just before starting system upgrade to ensure signatures of all upgraded packages can be properly verified.

When the system time is faulty, signing keys could be considered expired (or invalid) and signature checks on packages will fail. Synchronize the system clock regularly by using the Network Time Protocol daemon.

pacman-key depends on system time. If your system clock is not synchronized, system installation/upgrade may fail with:

error: PackageName: signature from "User <email@archlinux.org>" is invalid
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

If using ntpd, correct the system time (as root) with followed by hwclock -w.

Other NTP clients can be used. See time synchronization.

If correction of the system clock does not resolve the failure, try one of the following approaches:

Some packages could be corrupted or may be unsigned, causing failure. Remove each offending package from the system cache so it gets freshly downloaded, or clear the entire cache.

Remove or reset all the keys installed in your system by removing the directory (as root) and by rerunning followed by to re-add the default keys.

If you are not concerned about package signing, you can disable PGP signature checking completely. Edit /etc/pacman.conf to have the following lines under [options]:

SigLevel = Never
#LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required

You need to comment out any repository-specific SigLevel settings because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you do this, you do not need to set up a keyring with pacman-key. You can change those options later if you decide to enable package verification.

There are multiple possible sources of this problem:

• An outdated package.
• The clock being set to an incorrect date.
• Your ISP blocked the port used to import PGP keys.
• Your pacman cache contains copies of unsigned packages from previous attempts.
• is not correctly configured.

You might be stuck because of an outdated package when doing an upgrade synchronization.

Below are a few solutions that could work depending on your case.

See if upgrading the system can fix it first.

If you suspect that something is not working right with the keyserver, you could try to switch to the Ubuntu keyserver. To do this, edit and change the keyserver line to:

keyserver hkp://keyserver.ubuntu.com

If you suspect that your pacman cache at /var/cache/pacman/pkg/ might contain unsigned packages, try cleaning the cache manually or run:

# pacman -Sc

which removes all cached packages that have not been installed.

Sometimes when running you might encounter this error:

error: package-name: signature from "packager" is unknown trust

This occurs because the 's key used in the package is not present and/or not trusted in the local pacman-key gpg database. Pacman does not seem to always be able to check if the key was received and marked as trusted before continuing. This could also be because a key has expired since it was added to your keychain.

Mitigate by:

• Manually upgrading the archlinux-keyring package prior to the system upgrade, or
• refreshing your keys with pacman-key --refresh-keys, or
• resetting all the keys, or
• manually signing the untrusted key locally (not recommended), or
• setting temporarily SigLevel to (not recommended).

The last two options above break the chain of trust, and should be used with care.

In order to use a proxy when updating keys the option must be set in both and . See GnuPG#Use a keyserver for more information.