Pacman key error

To determine if packages are authentic, pacman uses GnuPG keys in a web of trust model. The current Master Signing Keys are found here. At least three of these Master Signing Keys are used to sign the Developer’s and Trusted User’s own keys. They are then used to sign their packages. Each user also has a unique PGP key, which is generated when you configure pacman-key. It is this web of trust that links the user’s key to the master keys.

Examples of webs of trust:

• Custom packages: Packages made and signed with a local key.
• Unofficial packages: Packages made and signed by a developer. Then, a local key was used to sign the developer’s key.
• Official packages: Packages made and signed by a developer. The developer’s key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.

Note: The HKP protocol uses 11371/tcp for communication. In order to get the signed keys from the servers (using pacman-key), this port is required for communication.

Setup

Configuring pacman

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 LocalFileSigLevel setting from the default pacman.conf, any packages you build, and install with pacman -U, will not need to be signed using makepkg.

Note: Although all official packages are now signed, as of November 2018 signing of the databases is a work in progress. If Required is set then DatabaseOptional should also be set.

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

/etc/pacman.conf

SigLevel = Required DatabaseOptional

TrustedOnly 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. Optional here would turn off a global Required for this repository.

Warning: The SigLevel TrustAll option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use TrustedOnly for all official repositories.

Initializing the keyring

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 ls -R / or find / -name foo or dd if=/dev/sda8 of=/dev/tty7). 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 (/etc/pacman.d/gnupg) and the GPG signing key of your system.

Note: If you need to run pacman-key --init on a computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either haveged or rng-tools on the target machine and start the corresponding service before running pacman-key --init.

Managing the keyring

Verifying the master keys

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’).

Adding developer keys

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 /etc/pacman.d/gnupg/gpg.conf (or by using the --keyserver 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.

Note: The archlinux-keyring package, which is a dependency of pacman, contains the latest keys. However keys can also be updated manually using pacman-key --refresh-keys (as root). While doing --refresh-keys, your local key will also be looked up on the remote keyserver, and you will receive a message about it not being found. This is nothing to be concerned about.

Adding unofficial keys

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:

   # pacman-key --recv-keys keyid

2. If otherwise a link to a keyfile is provided, download it and then run:

   # pacman-key --add /path/to/downloaded/keyfile

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.

Debugging with gpg

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

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

Tips and tricks

Upgrade system regularly

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 archlinux-keyring 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.

Update system time regularly

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.

Troubleshooting

Invalid signature errors

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 ntpd -qg 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:

Removing packages from cache

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

Resetting all the keys

Remove or reset all the keys installed in your system by removing the /etc/pacman.d/gnupg directory (as root) and by rerunning pacman-key --init followed by pacman-key --populate to re-add the default keys.

Disabling signature checking

Warning: Use with caution. Disabling package signing will allow pacman to install untrusted packages.

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.

Cannot import keys

There are multiple possible sources of this problem:

• An outdated archlinux-keyring 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.
• dirmngr is not correctly configured.

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

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

Upgrade the system

See if upgrading the system can fix it first.

Change keyserver

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 /etc/pacman.d/gnupg/gpg.conf and change the keyserver line to:

keyserver hkp://keyserver.ubuntu.com

Clean cached packages

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.

Signature is unknown trust

Sometimes when running pacman -Syu you might encounter this error:

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

This occurs because the packager‘s key used in the package package-name 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 TrustAll (not recommended).

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

Updating keys via proxy

In order to use a proxy when updating keys the honor-http-proxy option must be set in both /etc/gnupg/dirmngr.conf and /etc/pacman.d/gnupg/dirmngr.conf. See GnuPG#Use a keyserver for more information.

Note: If pacman-key is used without the honor-http-proxy option and fails, a reboot may solve the issue.

See also

• DeveloperWiki:Package Signing Proposal for Pacman
• Pacman Package Signing – 1: Makepkg and Repo-add
• Pacman Package Signing – 2: Pacman-key
• Pacman Package Signing – 3: Pacman
• Pacman Package Signing – 4: Arch Linux

A couple of days ago I got an additional laptop to take it on meetings.

As it will be used rarely and not as my main laptop – I decided to install Manjaro Linux there instead of usual Arch Linux – to take a look at the Manjaro itself and because don’t want to spend time with Arch configuration on a laptop, which be used even not each day.

After Manjaro installation (well – much easier than Arch, of course) I started the system upgrade, and…:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman -Syu
...
:: Proceed with installation? [Y/n]  
(413/413) checking keys in keyring                                                                                                             [] 100%
downloading required keys...
:: Import PGP key 256E/C7E7849466FE2358343588377258734B41C31549, "David Runge <dvzrv@archlinux.org>", created: 2019-10-01? [Y/n] y
error: key "David Runge <dvzrv@archlinux.org>" could not be imported
error: required key missing from keyring
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.

Well… Okay.

The first upgrade on o system with outdated packages, expected issues – no problem at all.

Do not perform the actions described below until you’ll read the actual reason.

Update archlinux-keyring

The first idea was to upgrade the archlinux-keyring util and it will update its keys:

$ sudo pacman -Sy archlinux-keyring
...
warning: archlinux-keyring-20191018-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) archlinux-keyring-20191018-1
...
-> Disabling key 44D4A033AC140143927397D47EFD567D4C7EA887...
==> Updating trust database...
gpg: next trustdb check due at 2020-01-22
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

But this didn’t help.

pacman-key --refresh-keys

Okay, let’s try update keys directly in the pacman-key‘s database:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman-key --refresh-keys
...
gpg: Total number processed: 133
gpg:              unchanged: 66
gpg:           new user IDs: 3
gpg:            new subkeys: 1
gpg:         new signatures: 1172
...
gpg: next trustdb check due at 2020-01-22

Nah, still something is wrong here:

[setevoy@setevoy-asus-laptop ~]$ pacman-key --list-sigs | grep Runge
gpg: Note: trustdb not writable
gpg: key E5BB298470AD4E41 was created 53 days in the future (time warp or clock problem)
gpg: key 6D42BDD116E0068F was created 11 days in the future (time warp or clock problem)
gpg: key 6D42BDD116E0068F was created 11 days in the future (time warp or clock problem)
gpg: key E5BB298470AD4E41 was created 53 days in the future (time warp or clock problem)
sig          54C28F4FF5A1A949 2014-10-06  David Runge <dave@sleepmap.de>
uid          [  full  ] David Runge <dave@sleepmap.de>
sig 3        54C28F4FF5A1A949 2017-05-07  David Runge <dave@sleepmap.de>
sig 3        54C28F4FF5A1A949 2015-01-04  David Runge <dave@sleepmap.de>
uid           [  full  ] David Runge <dave@c-base.org>
sig 3        54C28F4FF5A1A949 2017-05-07  David Runge <dave@sleepmap.de>
sig 3        54C28F4FF5A1A949 2015-10-20  David Runge <dave@sleepmap.de>
uid           [  full  ] David Runge <runge@pool.math.tu-berlin.de>
sig 3        54C28F4FF5A1A949 2017-05-07  David Runge <dave@sleepmap.de>
sig 3        54C28F4FF5A1A949 2014-10-03  David Runge <dave@sleepmap.de>
uid           [  full  ] David Runge <david.runge@campus.tu-berlin.de>
sig 3        54C28F4FF5A1A949 2017-05-07  David Runge <dave@sleepmap.de>
sig 3        54C28F4FF5A1A949 2014-10-03  David Runge <dave@sleepmap.de>
sig          54C28F4FF5A1A949 2017-05-07  David Runge <dave@sleepmap.de>

At least – the developer’s mailbox is not the same as in the error.

there is a hint, but I didn’t notice it

Removing /etc/pacman.d/gnupg

The next thing I did a try – to fully drop (backup, of course, not just delete) pacman‘s GPG database to re-initial it from scratch:

[setevoy@setevoy-asus-laptop ~]$ ls -l /etc/pacman.d/gnupg
total 6276
drwx------ 2 root root    4096 жов 21  2017 crls.d
-rw-r--r-- 1 root root      17 лис  8  2018 gpg-agent.conf
-rw-r--r-- 1 root root     114 жов 24  2015 gpg.conf
drwx------ 2 root root    4096 жов 24  2015 openpgp-revocs.d
...
-rw-r--r-- 1 root root   18920 сер 18 12:28 trustdb.gpg

Move it to backups:

[setevoy@setevoy-asus-laptop ~]$ mkdir ~/Backups
[setevoy@setevoy-asus-laptop ~]$ sudo mv /etc/pacman.d/gnupg Backups/

Run initialization:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman-key --init
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
gpg: Generating pacman keyring master key...
gpg: key FBADB7D2586D4A2F marked as ultimately trusted
gpg: directory '/etc/pacman.d/gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/etc/pacman.d/gnupg/openpgp-revocs.d/7F47A1EC7C894F56DD6F9E18FBADB7D2586D4A2F.rev'
gpg: Done
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u

Get keys:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman-key --populate
==> Appending keys from archlinux.gpg...
...

Let’s even update them:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman-key --refresh-keys
gpg: refreshing 132 keys from hkps://hkps.pool.sks-keyservers.net
...

Run the OS upgrade again:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman -Syu
...
downloading required keys...
:: Import PGP key 256E/C7E7849466FE2358343588377258734B41C31549, "David Runge <dvzrv@archlinux.org>", created: 2019-10-01? [Y/n]
error: key "David Runge <dvzrv@archlinux.org>" could not be imported
error: required key missing from keyring
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.

sd78dfv:?%67sdc!!!

pacman-key --recv-keys – a direct key’s import

Then I went to look for the key directly in the https://www.archlinux.org/master-keys database:

| David Runge | 0x41C31549 | Yes |

And try to import it directly:

[setevoy-asus-laptop setevoy]# pacman-key --recv-keys dvzrv@archlinux.org
gpg: key E5BB298470AD4E41 was created 53 days in the future (time warp or clock problem)
gpg: key 7258734B41C31549: 2 duplicate signatures removed
gpg: key 7258734B41C31549: 4 signatures not checked due to missing keys
gpg: key 7258734B41C31549: 2 signatures reordered
gpg: key 7258734B41C31549 was created 44 days in the future (time warp or clock problem)
gpg: key 7258734B41C31549 was created 44 days in the future (time warp or clock problem)
gpg: key 7258734B41C31549 was created 44 days in the future (time warp or clock problem)
gpg: key 7258734B41C31549 was created 44 days in the future (time warp or clock problem)
gpg: key 7258734B41C31549: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1
==> ERROR: Remote key not fetched correctly from keyserver.

Eeerrr….

gpg: key 7258734B41C31549 was created 44 days in the future (time warp or clock problem)

44 days in the future – WHAT?

The real cause and solution

Check the date on the operating system now:

[setevoy-asus-laptop setevoy]# date
sun, 18 серпня 2019 12:47:28 +0300

And by using hwclock to heck hardware’s time settings:

[setevoy-asus-laptop setevoy]# hwclock --show
2019-08-18 12:47:55.575491+03:00
Set the real time at this moment:
[setevoy-asus-laptop setevoy]# timedatectl set-time "2019-11-24 09:56:00"
[setevoy-asus-laptop setevoy]# hwclock --show
2019-11-24 09:56:03.404766+02:00

Repeat upgrade:

[setevoy@setevoy-asus-laptop ~]$ sudo pacman -Syu
...
(413/413) checking keys in keyring                                                                                                             [] 100%
downloading required keys...
:: Import PGP key 256E/C7E7849466FE2358343588377258734B41C31549, "David Runge <dvzrv@archlinux.org>", created: 2019-10-01? [Y/n]
(413/413) checking package integrity
...

And everything is working now.

Done.

Similar posts

• 05/08/2017 Arch Linux: keyserver receive failed: No keyserver available и ручной импорт ключа
• 05/06/2017 Arch Linux: запускаем Diablo 2
• 03/29/2017 Arch: Skype – звук и микрофон
• 03/16/2017 Arch: апплет батареи для ноутбука