Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

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

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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) - Thursday, 06 June 2019, 07:10 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Dave Reisner (falconindy)
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 3
Private No

Details

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 https://git.archlinux.org/arch-install-scripts.git/commit/?id=53debcefab227fc66ba85a9712b662145ff42d91 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.

Loading...