Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62826 - [pacman] [archlinux-keyring] dependency relationship is backwards, leading to populate failure

Attached to Project: Arch Linux
Opened by Eli Schwartz (eschwartz) - Thursday, 06 June 2019, 07:08 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 13 September 2020, 11:49 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Christian Hesse (eworm)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No


The pacman package has a dependency on archlinux-keyring, but does not actually need it. pacman does, in its default configuration, require signing, but that can of course be configured away -- and additionally, any keyring will do as long as it matches the mirrorlist sources. Thus, the keyring should be a distribution policy (e.g. membership in the base group) rather than a package dependency.

archlinux-keyring does not depend on pacman, but it should -- because its post-install script needs to run pacman-key. The current workaround is to check whether pacman-key exists and is executable before running the post-install, but the consequence of that is it is never executed at all.

The outcome of this is that when pacstrapping a new installation, the OOTB pacman keys are just the ones from the host system, for example an install ISO. Depending on how old that ISO is, the keyring could be quite out of date.

With the latest version of arch-install-scripts (see for details), pacstrap will ensure a working keyring exists in a newly installed Arch Linux rootfs, early enough that archlinux-keyring can make use of it to --lsign the master keys. This represented step 1 of getting the keyring to cleanly populate in a new Arch Linux installation.

Step two proposal:

remove depends+=('archlinux-keyring') from pacman
add depends+=('pacman') groups+=('base' 'base-devel') to archlinux-keyring.


This change should ensure that events like  FS#61296   FS#61304   FS#61309   FS#61312   FS#62355  do not happen again. In that case, the install scriptlet for archlinux-keyring tried to perform a one-time change, but the post_install was entirely skipped by pacstrap, and the post_upgrade was skipped in subsequent updates/reinstalls because the old keyring version that the migration was targeting, was not detected.
This task depends upon

Comment by Filipe Laíns (FFY00) - Sunday, 12 January 2020, 16:26 GMT
Can this please be fixed? Does anyone have comments on the proposed solution? If there aren't any concerns then why is this open since June??
Comment by Dave Reisner (falconindy) - Sunday, 12 January 2020, 17:48 GMT
Alternative solution: keep the existing dependency chain, add a post-transaction hook that runs `pacman-key --populate` for changes under /usr/share/pacman/keyrings/.
Comment by Filipe Laíns (FFY00) - Sunday, 12 January 2020, 17:52 GMT
That doesn't address this.

> The pacman package has a dependency on archlinux-keyring, but does not actually need it. pacman does, in its default configuration, require signing, but that can of course be configured away
Comment by Eli Schwartz (eschwartz) - Sunday, 12 January 2020, 17:53 GMT
Hmm, is now a good time to point out that I have archlinux32-keyring installed, but not populated (due to using --noscriptlet) for Reasons™?


Given the current base metapackage, archlinux-keyring should be added to the base *package*, removed from pacman, and made to depend on pacman. Installing base would require the keyring, and order it before pacman.
Comment by Eli Schwartz (eschwartz) - Thursday, 07 January 2021, 02:19 GMT
Recently reminded of this due to helping someone on IRC with a semi-broken install mere days after installing Arch from an older ISO. My key expired on 2020-10-17 but got renewed in the 2020-08-17 keyring update. People using the 2020-08-01 ISO to install Arch on or after 2020-12-11, then get (temporarily) broken keyrings.

After some people spent a while trying to figure out what was wrong, I linked them this bug and told the user to reinstall the keyring, which fortunately always works for this because it just needed to repopulate the refreshed keydata, not edit keys in the install script, but... not really good UI here, honestly.

It would be nice to get this fixed...
Comment by Levente Polyak (anthraxx) - Friday, 08 January 2021, 18:31 GMT
I agree this should be fixed and I believe the proposed solution sounds appropriate.

pacman-key is being called in the install script, so declaring pacman as dependency of archlinux-keyring sounds like the right thing to do
furthermore pacman itself doesn't require archinux-keyring, but thats a property required to run "an Arch Linux", which is better reflected by adding it to the virtual base package.

So as far as I can see, we can two things for free: a more technical correct declaration/definition and a fix for this issue. This issue lays around for nearly two years now, if its a matter of workload I'm happily helping to get it sorted. Otherwise it would be nice to hear concerns if there are any.
Comment by Doug Newgard (Scimmia) - Saturday, 22 January 2022, 22:42 GMT
This is a real issue again, as there have been multiple keyring updates this month to fix expirations and trust issues.

Another simple solution would be to just use `gpg --homedir /etc/pacman.d/gnupg/` instead of pacman-key in the post_install script. gnupg gets installed before archlinux-keyring.

Edit: Ok, so --populate is more complex than I thought. This may not be a good option.
Comment by Levente Polyak (anthraxx) - Saturday, 22 January 2022, 23:07 GMT
Nobody complained for a year so I'll implement the proposed solution, add the dependency in archlinux-keyring and base.
Comment by Doug Newgard (Scimmia) - Wednesday, 27 April 2022, 13:52 GMT
With alucryd using a key that's only trusted in the latest keyring package, this has become an issue again.