FS#55160 - [gnupg] gnupg does not work in a systemd container

Attached to Project: Arch Linux
Opened by Stefan (steinwanderer) - Tuesday, 15 August 2017, 21:57 GMT
Last edited by David Runge (dvzrv) - Monday, 09 May 2022, 09:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
David Runge (dvzrv)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

gnupg is not functional when running within a systemd container, can not sign or verify packages.

Additional info:
* package version(s)

gnupg 2.1.23-1
systemd 234.11-6

* config and/or log files etc.

console:

gpg: error searching keyserver: Server indicated a failure
gpg: keyserver search failed: Server indicated a failure

journal:

systemd[24]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
systemd[24]: Reached target Timers.
systemd[24]: Starting D-Bus User Message Bus Socket.
systemd[24]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
systemd[24]: Reached target Paths.
systemd[24]: Listening on GnuPG network certificate management daemon.
systemd[24]: Listening on D-Bus User Message Bus Socket.
systemd[24]: Reached target Sockets.
systemd[24]: Reached target Basic System.
systemd[24]: Reached target Default.
systemd[24]: Startup finished in 13ms.
systemd[1]: Started User Manager for UID 1000.
systemd[24]: Started GnuPG network certificate management daemon.
dirmngr[36]: dauerhaft geladene Zertifikate: 146
dirmngr[36]: zwischengespeicherte Zertifikate: 0
dirmngr[36]: vertrauenswürdige Zertifikate: 146 (145,0,0,1)
dirmngr[36]: command 'KS_SEARCH' failed: Server zeigt einen unbestimmten Fehler an <Quelle nicht angegeben>
dirmngr[36]: command 'KS_SEARCH' failed: Server zeigt einen unbestimmten Fehler an <Quelle nicht angegeben>

Steps to reproduce:

create a new container and boot it:

# btrfs subvolume create /var/lib/machines/archbuild
# pacstrap -c -d -i /var/lib/machines/archbuild base gnupg --ignore linux
# /usr/bin/systemd-nspawn --boot --machine=archbuild

create a new user and login, then do:

# LANG=C gpg --debug 1024 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys 9741E8AC

gpg: Note: no default option file '/home/builder/.gnupg/gpg.conf'
gpg: enabled debug flags: ipc
gpg: directory '/home/builder/.gnupg' created
gpg: keybox '/home/builder/.gnupg/pubring.kbx' created
gpg: DBG: chan_3 <- # Home: /home/builder/.gnupg
gpg: DBG: chan_3 <- # Config: [none]
gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.23
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_SEARCH -- 9741E8AC
gpg: DBG: chan_3 <- ERR 219 Server zeigt einen unbestimmten Fehler an <Quelle nicht angegeben>
gpg: error searching keyserver: Server indicated a failure
gpg: keyserver search failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: secmem usage: 0/32768 bytes in 0 blocks

Maybe relevant:

https://dev.gnupg.org/T2889
https://bugs.archlinux.org/task/52234

The mentioned workaround from above doesn't work on this one:
# echo "standard-resolver" >> ~/.gnupg/dirmngr.conf

I guess this is DNS related, too. Host for the above container uses systemd-networkd and systemd-resovled with default settings.
Gnupg on the "real" shell (outside the container) on the same host works just fine.
This task depends upon

Closed by  David Runge (dvzrv)
Monday, 09 May 2022, 09:32 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Connection issue due to DNS configuration. This is not related to the packaging of either gnupg or systemd.
Comment by Stefan (steinwanderer) - Wednesday, 16 August 2017, 15:52 GMT
I just found out, it is maybe related to systemd-resolved. If I change "DNSSEC" to "no", it works.

#/etc/systemd/resolved.conf

DNSSEC=no => works
DNSSEC=yes => don't works (I guess, it is expected)
DNSSEC=allow-downgrade => don't works (That should work imho)
Comment by John (graysky) - Wednesday, 18 October 2017, 22:07 GMT
I am experiencing this as well but not in a systemd-container, in an linux container (lxc) connecting via ssh from my host machine:

% ssh container
me@container % touch testfile
me@container % gpg -c testfile
gpg: problem with the agent: No pinentry
gpg: error creating passphrase: Operation cancelled
gpg: symmetric encryption of 'testfile' failed: Operation cancelled
Comment by Gaetan Bisson (vesath) - Friday, 08 December 2017, 19:39 GMT
I'm unassigning myself since there is nothing I can do here: if this is a gnupg bug (which is unlikely given that changing DNSSEC to no in systemd-resolved's config makes things work) please report it upstream. Cheers.
Comment by David Runge (dvzrv) - Monday, 09 May 2022, 09:31 GMT
@steinwanderer: This seems to be a DNS configuration issue and not a problem with either the packaging of gnupg or systemd.
@graysky: Your reported issue seems unrelated to this issue.

Loading...