Arch Linux

GnuPG now conflicting with dirmngr is perfectly fine; dirmngr has been integrated into gnupg and the separate package will be removed when gnupg moves to [core].

The pacman-key issue should be investigated but seems independent.

pacman-key is a very light wrapper around GPG:

# gpg --homedir /etc/pacman.d/gnupg/ --no-permission-warning --recv-keys 941C2A25
gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect call failed
gpg: keyserver receive failed: No dirmngr

It seems the new dirmngr does not work well with --homedir; could you report this upstream to http://bugs.gnupg.org/ ?

This is nothing to do with --homedir (which works fine). It is gpg failing (to create a socket?) when run as root.

The issue seems to be only with converting /etc/pacman.d/gnupg/ from the old key format to the new one. Apparently that requires dirmngr which somehow fails to launch. However, once the conversion has been done, everything works again as normal.

It seems that if I do:

sudo -i dirmngr < /dev/null

This creates what is needed for pacman-key to find the IPC to dirmngr, and pacman-key works out of the box. Could you confirm this?

Confirmed this works. I thought gpg was supposed to do this automatically.

I'll reply to my mailing list post upstream to see if anyone has other ideas.

Or we could just run `pacman-key --populate` from scratch upon upgrading to gnupg-2.1...

Upstream: https://bugs.g10code.com/gnupg/issue1762

pacman-key --populate is not enough for pacman-key --recv-key to work. I had tried that.

The `dirmngr </dev/null` trick seems to be needed on install as well, as I encountered the same error and needed it to fix it on a new Arch Linux install.

So it should probably be done on post_install as well as post_upgrade.

It should only be required when migrating a keyring from the old to the new format. Does the ISO contain a keyring with the old format?

If it does, could you confirm that running dirmngr in post_install solves the issue you experience? Thanks.

I didn't actually use an ISO, the install was done from a running/up-to-date Arch system. Also I used pacstrap's -G option, so there was no keyring copied to the new install/guest, instead a new one had to be created (pacman-key --init); I don't think it matters though. Either way (whether -G/pacman-key --init was used, or the keyring is copied from host) when I try to do a --recv--keys it fails, apparently because things under /root/.gnupg haven't been initialized, which the `dirmngr </dev/null` does.

Actually, after a bit more testing it seems that might not be needed after all, simply creating /root/.gnupg is enough to fix it. From what I can tell a simple `[[ -d /root/.gnupg ]] || mkdir /root/.gnupg` instead of calling dirmngr is enough to make things work as expected, but it should happen on post_install as well for new installs.

I should say however that I only tried on new installs with a keyring already to the new format (from host), or creating a new one (pacman-key --init), both of which requires simply the folder to be created, but not updating a system and converting the current keyring, as seems to be the original issue in this bug report. That might be a separate/different issue where dirmngr is still required to be called on post_upgrade (as I assume the folder would have then already existed?).

I do not want any package (including gnupg) to interact with user home directories upon installing/upgrading. That would be wrong. If creating /root/.gnupg really needs to be done in new chroots, then this should be created by the install scripts, or perhaps part of the filesystem package. If you agree, could you file a bug against, say, arch-install-scripts?

I agree that messing with home dir probably isn't the best upon installing/upgrading (although that's what being done indirectly, via dirmngr).

But I'm not sure if this should be addressed in arch-install-scripts though; Maybe ensuring that the folder exists could be added to pacman-key, so that it always works regardless of how it came to be called, since as Allan said above it is a wrapper around gpg, and this is working around a bug in gpg?

Hi, this morning while trying to do a full update, pacman failed with the following error:

error: key "A6234074498E9CEE" could not be looked up remotely
error: required key missing from keyring
error: failed to commit transaction (unexpected error)

and that led me to the following bug report: https://bugs.archlinux.org/task/43759
and to the following thread: https://bbs.archlinux.org/viewtopic.php?id=193382

Digging a bit I found that, in order to comunicate with the keyserver, gpg inovkes dirmng but this is started as a daemon:

# ps -Af | grep dirmngr
root 12302 1 0 18:06 ? 00:00:00 dirmngr --daemon --homedir /etc/pacman.d/gnupg

The problem is that according to man pages, dirmngr ignores the --homedir option if --daemon is passed and it relies instead on the environment variable GNUPGHOME:

[root@530U3C daddona]# pacman-key --recv-keys A6234074498E9CEE
gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect call failed
gpg: keyserver receive failed: No dirmngr
==> ERROR: Remote key not fetched correctly from keyserver.
[root@530U3C daddona]# GNUPGHOME=/etc/pacman.d/gnupg/ pacman-key --recv-keys A6234074498E9CEE
gpg: key 498E9CEE: "Christian Hesse (Arch Linux Package Signing) <arch@eworm.de>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
==> Updating trust database...
gpg: next trustdb check due at 2016-01-22

Could you see if this is fixed with gnupg-2.1.4-1 now in [core]?

No, it is not fixed yet: dirmngr still ignores the --homedir option and tries to use /root/.gnupg instead.

Looks like dirmngr --daemon --homedir /etc/pacman.d/gnupg is working now. Can we change to using this? I selfishly need to run pacstrap inside a docker container and it isn't working with the /dev/null workaround currently in place in the gnupg.install. (dirmngr hangs using 100% cpu because /dev/null isn't a real device).

Jeremy, could you try without running dirmngr altogether? It if still fails and we still need a workaround sure, I'll take `dirmngr --daemon --homedir /etc/pacman.d/gnupg`. Cheers.

aurman maintainers say gnupg key import is broken, see: https://github.com/eli-schwartz/aurman/commit/fa2c902b215b74ab31d1c31bf40f9d62cfd3a3bd on the error:

$ pacaur -S aurman
...
==> Verifying source file signatures with gpg...
aurman_sources git repo ... FAILED (unknown public key 465022E743D71E39)

I wrote that commit, and you're utterly wrong.

GnuPG is not broken, *your system is broken*.

Moreover, it is physically impossible for you to get the output you did, if the codepath you just linked to was actually run.

If you had posted the full output, we'd be able to see how the error message you refer to *is not there*.

Moreover, this bug is about pacman, not makepkg and not AUR helpers. Your makepkg/AUR helper woes are not on-topic for this bug report.

Do not reopen this bug for moronic reports concerning unsupported tools.

The report was reopened months ago with:

Comment by Jeremy (jeremyd) - Sunday, 18 March 2018, 08:53 GMT-4
Looks like dirmngr --daemon --homedir /etc/pacman.d/gnupg is working now. Can we change to using this? I selfishly need to run pacstrap inside a docker container and it isn't working with the /dev/null workaround currently in place in the gnupg.install. (dirmngr hangs using 100% cpu because /dev/null isn't a real device).

Then got *hijacked* by a moronic report yesterday. :)

If you're going to close it as WORKSFORME, please confirm it is for the real issue, not the hijack. :)

Eli: Only a few hours after reopening this report I asked Jeremy a simple question and he never replied. So I guess you're right: I shouldn't have closed as "Works for me" but as "No response".

Everybody else: I will ignore all further comments that do not concern Jeremy's proposed fix or my reply to him. Please create new bug reports for anything else.

Sorry, this tracker seems broken as i swear it took 5 months for a reply after I reopened this although the timestamps show a single day :(((((

I haven't had a chance to reproduce again, because I just use the archlinux docker image now and like I said.. tracker broken took months. I'll close this out as .. no longer needed. Thanks!

Cheers!