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 Jonas Witschel (diabonas) - Thursday, 28 July 2022, 16:28 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
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 100%
Votes 6
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

Closed by  Jonas Witschel (diabonas)
Thursday, 28 July 2022, 16:28 GMT
Reason for closing:  Implemented
Additional comments about closing:  archlinux-keyring 20220713-2, base 3-1, pacman 6.0.1-6
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.
Comment by Jonas Witschel (diabonas) - Tuesday, 19 July 2022, 14:14 GMT
With the release of archlinux-keyring 20220713-1 this has become and issue once again, e.g. for dvzrv's new key. Part of the solution, i.e. adding archlinux-keyring to base, has been implemented by anthraxx back in January (, but no actual package containing this change has been released. Since the other two proposed changes (making archlinux-keyring depend on pacman and adding it to base-devel; removing the archlinux-keyring dependency from pacman) seem to have reached a consensus, I have implemented them in archlinux-keyring 20220713-2 ( and pacman 6.0.1-6 (, as well as releasing the modified base 3-1 package.

These packages are currently in [testing], please do as the name of that repo implies and try the changes in existing installations, new installations using pacstrap, build chroots, containers etc. ;)
Comment by Levente Polyak (anthraxx) - Tuesday, 19 July 2022, 15:11 GMT
This change puts the existing build chroot in kind of a limbo. They do have archlinux-keyring already installed as it used to be a dependency of pacman. But with this setup nothing depends on it and its not marked as explicitly installed because base-devel will only be applied during `mkarchroot`.
Comment by Jonas Witschel (diabonas) - Tuesday, 19 July 2022, 15:18 GMT
Fair point, but does it actually matter apart from "cosmetic" reasons when somebody runs "pacman -Qdt" inside the chroot? And would there be a way to avoid this? The reason for the dependency switch is that we need to guarantee that pacman gets installed before archlinux-keyring, so it is not enough to add archlinux-keyring to base because does not guarantee that pacman gets installed first.

IMHO the best way to fix this would be to recreate our build chroots regularly, but that's a topic for another (probably already existing) bug report ;)
Comment by Levente Polyak (anthraxx) - Tuesday, 19 July 2022, 15:37 GMT
Yep, i dont see it as a blocker for this changes here, but during taking a second look I realized this shortcoming -- hence dropped a line.

On a long shot we should auto clean chroot packages and have an internal chroot version to autonuke whenever we need to introduce "breaking changes". But thats really more a followup for devtools :)
Comment by Jonas Witschel (diabonas) - Tuesday, 19 July 2022, 15:52 GMT
Ah sure, I just wasn't clear on whether you were implying that this change would require additional changes to devtools to make it work :) I am all for listing all possible implications that these changes might have, makes it much easier to figure out things going awry early! So keep going as long as the changes can't break actual user systems yet :D