FS#42798 - [gnupg, pacman] Gnupg-2.1 does not work well with pacman-key

Attached to Project: Arch Linux
Opened by Mateusz Paluszkiewicz (TheAifam5) - Saturday, 15 November 2014, 13:26 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 26 June 2018, 00:07 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dan McGee (toofishes)
Allan McRae (Allan)
Gaetan Bisson (vesath)
Dave Reisner (falconindy)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Steps to reproduce:
1. Enable Testing repository.
2. Update.
3. Try to add custom key eg: pacman-key -r 5EE46C4C

Logs:
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.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Tuesday, 26 June 2018, 00:07 GMT
Reason for closing:  None
Comment by Gaetan Bisson (vesath) - Saturday, 15 November 2014, 19:39 GMT
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.
Comment by Allan McRae (Allan) - Sunday, 16 November 2014, 09:20 GMT
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

Comment by Gaetan Bisson (vesath) - Monday, 17 November 2014, 05:18 GMT
It seems the new dirmngr does not work well with --homedir; could you report this upstream to http://bugs.gnupg.org/ ?
Comment by Allan McRae (Allan) - Monday, 17 November 2014, 15:40 GMT
This is nothing to do with --homedir (which works fine). It is gpg failing (to create a socket?) when run as root.
Comment by Gaetan Bisson (vesath) - Tuesday, 18 November 2014, 03:36 GMT
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?
Comment by Allan McRae (Allan) - Tuesday, 18 November 2014, 03:41 GMT
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.
Comment by Gaetan Bisson (vesath) - Tuesday, 18 November 2014, 03:42 GMT
Or we could just run `pacman-key --populate` from scratch upon upgrading to gnupg-2.1...
Comment by Gaetan Bisson (vesath) - Tuesday, 18 November 2014, 03:42 GMT Comment by Allan McRae (Allan) - Tuesday, 18 November 2014, 03:50 GMT
pacman-key --populate is not enough for pacman-key --recv-key to work. I had tried that.
Comment by Olivier Brunel (jjacky) - Saturday, 10 January 2015, 14:12 GMT
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.
Comment by Gaetan Bisson (vesath) - Sunday, 11 January 2015, 00:30 GMT
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.
Comment by Olivier Brunel (jjacky) - Sunday, 11 January 2015, 17:34 GMT
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?).
Comment by Gaetan Bisson (vesath) - Monday, 12 January 2015, 02:52 GMT
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?
Comment by Olivier Brunel (jjacky) - Monday, 12 January 2015, 13:10 GMT
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?
Comment by Maurizio D'Addona (mauritiusdadd) - Tuesday, 10 February 2015, 17:29 GMT
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
Comment by Gaetan Bisson (vesath) - Saturday, 16 May 2015, 20:35 GMT
Could you see if this is fixed with gnupg-2.1.4-1 now in [core]?
Comment by Maurizio D'Addona (mauritiusdadd) - Sunday, 17 May 2015, 05:15 GMT
No, it is not fixed yet: dirmngr still ignores the --homedir option and tries to use /root/.gnupg instead.
Comment by Jeremy (jeremyd) - Sunday, 18 March 2018, 12:53 GMT
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).
Comment by Gaetan Bisson (vesath) - Monday, 19 March 2018, 01:51 GMT
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.
Comment by soloturn (soloturn) - Sunday, 24 June 2018, 21:53 GMT
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)
Comment by Eli Schwartz (eschwartz) - Sunday, 24 June 2018, 22:43 GMT
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.
Comment by Gaetan Bisson (vesath) - Monday, 25 June 2018, 02:28 GMT
Do not reopen this bug for moronic reports concerning unsupported tools.
Comment by Eli Schwartz (eschwartz) - Monday, 25 June 2018, 12:42 GMT
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. :)
Comment by Gaetan Bisson (vesath) - Monday, 25 June 2018, 17:22 GMT
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.
Comment by Jeremy (jeremyd) - Monday, 25 June 2018, 21:01 GMT
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!
Comment by Gaetan Bisson (vesath) - Tuesday, 26 June 2018, 00:06 GMT
Cheers!

Loading...