Page MenuHome GnuPG
Create Task
Maniphest T4931

gnupg unusable with a long path to $HOME
Closed, ResolvedPublic
Actions

Description

Description of problem:
Our (ci-dnf-stack) test suite is frequently nested in many subdirs and we have only a little control over the path length. We frequently hit gpg2 path length issues.

Version-Release number of selected component (if applicable):
gnupg2-2.2.18-2.fc31

How reproducible:
Always

Steps to Reproduce:
export HOME=/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long-path; mkdir -p $HOME; gpg2 --batch --passphrase '' --quick-gen-key key-name default default 0

Actual results:
gpg: directory '/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long-path/.gnupg' created
gpg: keybox '/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long-path/.gnupg/pubring.kbx' created
gpg: can't connect to the agent: File name too long
gpg: agent_genkey failed: No agent running
gpg: key generation failed: No agent running

Expected results:
gpg: directory '/tmp/short-path/.gnupg' created
gpg: keybox '/tmp/short-path/.gnupg/pubring.kbx' created
gpg: /tmp/short-path/.gnupg/trustdb.gpg: trustdb created
gpg: key 4B4DACD10E5B0939 marked as ultimately trusted
gpg: directory '/tmp/short-path/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/tmp/short-path/.gnupg/openpgp-revocs.d/C058F09DC507F4396C8C4E754B4DACD10E5B0939.rev'

As far as I know this limitation is coming from the very deep assumptions of gnupg2 being able to create an UNIX socket in the .gnupg directory and refer to it with absolute path when connecting to it.

Event Timeline

t8m created this task.Apr 29 2020, 4:03 PM
t8m created this object in space S1 Public.
• werner triaged this task as Normal priority.Apr 30 2020, 9:32 AM
• werner added a project: FAQ.
• werner added a subscriber: • werner.

You are still using the old way of having the sockets in ${GNUPGHOME:-~/.gnupg}. Since 2.2.13 we use

If a /run/user/$UID directory exists, that directory is now used
for IPC sockets instead of the GNUPGHOME directory.  This fixes
problems with NFS and too long socket names and thus avoids the
need for redirection files.

gpgconf: New commands --create-socketdir and --remove-socketdir,
new option --homedir.

This works by using a hash of the directory name below /run/user/$UID/gnupg as directory for the sockets.
With 2.1.20 we also added:

A socket directory for a non standard GNUGHOME is now created on
the fly under /run/user.  Thus "gpgconf --create-socketdir" is now
optional.  The use of "gpgconf --remove-socketdir" to clean up
obsolete socket directories is however recommended to avoid
cluttering /run/user with useless directories.

So what you need to do with such old versions to run "gpgconf --create-socketdir " once to make sure that a dedicated direcory for a non-standard home directory is created. However for the standard home directory this is not needed; well except that a directory /run/user/$UID exists.

t8m added a comment.Apr 30 2020, 11:03 AM

Can you please clarify? Let's assume I am using current gnupg version (2.2.20) and /run/user/$UID exists. Everything should work seamlessly, should it?

t8m added a comment.Apr 30 2020, 11:04 AM

Also I suppose the 2.1.20 version above is typo and 2.2.20 is actually meant.

• werner added a comment.Apr 30 2020, 12:22 PM

Yes, with current gnupg it works w/o problems. Well, unless systemd decided to remove the directory. There is a loginctl(1) way to avoid this.

I really meant 2.1.20; I quoted from the NEWS file 2.1.20.

gpgconf --list-dirs socketdir

comes handy to check gnupg's idea of the socket directory.

• gniibe closed this task as Resolved.Mar 16 2022, 3:03 PM
• gniibe claimed this task.
• gniibe added a project: Not A Bug.