more key nightmares

Links: Arch - package signing

TLDR: in 2024, one's system, gpg keyservers, and Arch repositories all need to be *up*, properly configured, and current, to accomplish a standard Arch pacman Syu. Solutions given in decreasing order of intervention severity.

overview

"Key" conflicts or expiry during pacman updates have become the most consistent annoyance in Arch, (alongside PulseAudio, more Linux-wide). Eg, in 2024, waiting even two weeks between system updates likely will spawn an unrecoverable, unintuitive pacman key failure during pacman -Syu. What is happening?

Pacman used to just check a hash of the application package. NOW, Arch additionally checks hashed signature keys for each application's creator/repository uploader. The shift to increased verification led to use of an additional application: gpg. A further complication -- gpg stores and retrieves keys from a dedicated repository, a "keyserver", which is separate from the application repository. A yet further complication is that gpg deposits the latest keys into user's system, in /etc/pacman.d/gnupg and does not regularly update these.

pacman is still the update manager, but gpg is now a critical adjuvant app, and which must handshake its keys with pacman during each update, yet does not update its keys between pacman updates. Immense time can be lost navigating this setup; this post only has the bandwith to list solutions. Basically, if any pacman key failures, I first attempt to update the keys (pacman-key --refresh-keys) and then I go nuclear. I don't have days to waste.

Solutions in decreasing order intervention severity.

---

thermo-nuclear

# nano /etc/pacman.conf
# temporary key solution: add SigLevel never and
# comment-out default "Required"
SigLevel = Never
# SigLevel = Required DatabaseOptional

A regular pacman-Syu now works. After update success, and a reboot, we reset /etc/pacman.conf back to default "Required".

We've accomplished the update, but now we find that the problem with keys still exists. That is, we still can't, eg., run pacman-key --populate, without the same error messages and Catch-22 with 'pacman-key --init' that we experienced earlier:

# pacman-key --populate
==> ERROR: There is no secret key available to sign with.
==> Use 'pacman-key --init' to generate a default secret key.
# pacman-key --refresh
gpg: error reading key: No public key

The Catch 22 is that we're driven to run 'pacman-key --init', but 'pacman-key --init' fails 100% of the time, stating we have no public key, LOL. "I can't make what you need since you don't already have it".  In 2024, I don't know a way to circumvent this keys issue without significant time-wasting alternatives. I just give it a key.

# gpg --gen-key --homedir /home/USER/.gnupg --passphrase "PASSWORD" --pinentry-mode loopback
gpg: WARNING: unsafe ownership on homedir '/home/foo/.gnupg'
GnuPG needs to construct a user ID to identify your key.
Real name:

After all of this, we'll get some success message...

gpg: /home/foo/.gnupg/trustdb.gpg: trustdb created
gpg: directory '/home/foo/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/foo/.gnupg/openpgp-revocs.d/BFA0F3753DA6EA552E08958F06E36EA3F9E270C0.rev'
public and secret key created and signed.

...after which...

# pacman-key --init
# pacman-key --populate

...work normally. Now we can do regular pacman updates with regular keyring checks. We have to repeat the laborious process however, typically when it's been a few weeks or longer between updates.

nuclear

stackexchange wisdom

# gpgconf --kill gpg-agent
# rm -r /etc/pacman.d/gnupg
# rm -r /root/.gnupg
# rm -r /home/foo/.gnupg

# rm -r /etc/pacman.d/gnupg
# rm -r /root/.gnupg

...after which

# pacman-key --init

light cure

A typical usual cure...

# pacman -Sy archlinux-keyring -

...after which try the stronger

# pacman-key --refresh-keys

catch-22 circular fail

Notice 100% gpg reliance.

# pacman-key --populate
gpg: problem with fast path key listing: No such file or directory - ignored
==> ERROR: There is no secret key available to sign with.
==> Use 'pacman-key --init' to generate a default secret key.
# pacman-key --init
gpg: problem with fast path key listing: No such file or directory - ignored
==> Generating pacman master key. This may take some time.
gpg: Generating pacman keyring master key...
gpg: agent_genkey failed: No such file or directory
gpg: key generation failed: No such file or directory
gpg: Done
==> Updating trust database...
gpg: no need for a trustdb check

directly into gpg: gpgconf

# gpgconf --list-components
gpg:OpenPGP:/usr/bin/gpg
gpgsm:S/MIME:/usr/bin/gpgsm
keyboxd:Public Keys:/usr/lib/gnupg/keyboxd
gpg-agent:Private Keys:/usr/bin/gpg-agent
scdaemon:Smartcards:/usr/lib/gnupg/scdaemon
tpm2daemon:TPM:/usr/lib/gnupg/tpm2daemon
dirmngr:Network:/usr/bin/dirmngr
pinentry:Passphrase Entry:/usr/bin/pinentry

# gpgconf --kill gpg-agent