FS#54335 - [gpg] pacman-key --populate will not run in arch-chroot

Attached to Project: Arch Linux
Opened by Gordon Willem Klok (gwk) - Wednesday, 07 June 2017, 02:00 GMT
Last edited by Gaetan Bisson (vesath) - Friday, 08 December 2017, 19:54 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Using a script based off: https://github.com/moby/moby/blob/master/contrib/mkimage-arch.sh#L100
the pacman-key --populate command will refuse to sign the 5 root arch developer keys with the local key created by packman-key --init
(If I am understanding how the arch key signing system works). Subsequent package installation is then impossible.

e.g.
+ arch-chroot /var/tmp/rootfs-archlinux-1KZFsMmVCm /bin/sh -c 'haveged -w 1024; pacman-key --init; pkill haveged; pacman -Rs --noconfirm haveged ; pacman-key --populate archlinux; pkill gpg-agent'
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 B8ED2CA016A40DB7 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/26B4EC2C9E33C09877CFAB1DB8ED2CA016A40DB7.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
checking dependencies...

Packages (1) haveged-1.9.1-2

Total Removed Size: 0.13 MiB

:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing haveged [#######################################################################] 100%
==> Appending keys from archlinux.gpg...
==> Locally signing trusted keys in keyring...
-> Locally signing key 684148BB25B49E986A4944C55184252D824B18E8...
==> ERROR: 684148BB25B49E986A4944C55184252D824B18E8 could not be locally signed.
-> Locally signing key 91FFE0700E80619CEB73235CA88E23E377514E00...
==> ERROR: 91FFE0700E80619CEB73235CA88E23E377514E00 could not be locally signed.
-> Locally signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7...
==> ERROR: AB19265E5D7D20687D303246BA1DFB64FFF979E7 could not be locally signed.
-> Locally signing key 0E8B644079F599DFC1DDC3973348882F6AC6A4C2...
==> ERROR: 0E8B644079F599DFC1DDC3973348882F6AC6A4C2 could not be locally signed.
-> Locally signing key 44D4A033AC140143927397D47EFD567D4C7EA887...
==> ERROR: 44D4A033AC140143927397D47EFD567D4C7EA887 could not be locally signed.

This looks like maybe a reoccurrence of https://bugs.archlinux.org/task/43002

I was able to work around this by running packman-key --init / --populate outside the chroot using the --gnupg option to
specify the directory outside the chroot.

Additional info:
* package version(s)
pacman 5.0.1-5
systemd 232-8
linux 4.11.3-1
gnupg 2.1.21-1

* config and/or log files etc.

Steps to reproduce:
Run packman-key --populate under arch-chroot
This task depends upon

Closed by  Gaetan Bisson (vesath)
Friday, 08 December 2017, 19:54 GMT
Reason for closing:  No response
Comment by Daniel M. Capella (polyzen) - Wednesday, 07 June 2017, 05:20 GMT
Same issue as  FS#54271 ?
Comment by userwithuid (userwithuid) - Wednesday, 07 June 2017, 05:24 GMT
This is most likely a duplicate of https://bugs.archlinux.org/task/54271 . If true, it should be fixed with gnupg 2.1.21-2 (currently in testing).

Edit: Damn, 4 minutes too late...
Comment by Doug Newgard (Scimmia) - Tuesday, 13 June 2017, 14:36 GMT
I saw this with testing-x86_64-build recently; it's not the same as  FS#54271 
Comment by Gaetan Bisson (vesath) - Tuesday, 13 June 2017, 18:14 GMT
1. How did you create your chroot? I am unable to reproduce your issue with a simple `pacstrap -c . base sudo haveged` so there must be something peculiar about your chroot.

2. Why do you kill haveged before running `pacman-key --populate`? Gnupg needs entropy to sign the master keys. (Edit: This depends on the key type, but still...) There is no good reason ever to kill haveged...
Comment by Doug Newgard (Scimmia) - Tuesday, 13 June 2017, 21:27 GMT
vesath, I saw this when I already had a testing chroot that updated the archlinux-keyring package.
Comment by Allan McRae (Allan) - Tuesday, 14 November 2017, 23:51 GMT
$ sudo arch-chroot /var/lib/archbuild/testing-x86_64/root pacman-key --populate
==> Appending keys from archlinux.gpg...
==> Locally signing trusted keys in keyring...
-> Locally signing key DDB867B92AA789C165EEFA799B729B06A680C281...
-> Locally signing key 684148BB25B49E986A4944C55184252D824B18E8...
-> Locally signing key 91FFE0700E80619CEB73235CA88E23E377514E00...
-> Locally signing key AB19265E5D7D20687D303246BA1DFB64FFF979E7...
-> Locally signing key 0E8B644079F599DFC1DDC3973348882F6AC6A4C2...
-> Locally signing key 44D4A033AC140143927397D47EFD567D4C7EA887...
...

Looks fine to me?
Comment by Allan McRae (Allan) - Tuesday, 14 November 2017, 23:52 GMT
Reassign me if it is actually a pacman-key bug and not gpg.

Loading...