Page MenuHome GnuPG

`gpg-agent --gpgconf-list` returns a non-zero error code 2 if $HOME is non-existent, causing `gpgconf` to fail
Closed, ResolvedPublic

Description

0 dkg@alice:~$ HOME=/nonexistent gpg-agent --gpgconf-list
gpg-agent[599306]: can't create directory '/nonexistent/.gnupg': No such file or directory
gpgconf-gpg-agent.conf:16:"/nonexistent/.gnupg/gpg-agent.conf
verbose:8:
quiet:8:
debug-level:24:"none:
log-file:8:
default-cache-ttl:24:600:
default-cache-ttl-ssh:24:1800:
max-cache-ttl:24:7200:
max-cache-ttl-ssh:24:7200:
enforce-passphrase-constraints:8:
min-passphrase-len:24:8:
min-passphrase-nonalpha:24:1:
check-passphrase-pattern:24:
max-passphrase-days:24:0:
enable-passphrase-history:8:
no-grab:8:
ignore-cache-for-signing:8:
no-allow-external-cache:8:
no-allow-mark-trusted:8:
disable-scdaemon:8:
enable-ssh-support:0:
ssh-fingerprint-digest:24:"md5:
no-allow-loopback-pinentry:8:
allow-emacs-pinentry:8:
pinentry-timeout:24:0:
enable-extended-key-format:8:
grab:8:
2 dkg@alice:~$

the result of returning a non-zero error code here is that gpgconf --list-options gpg-agent fails hard for user accounts with a non-existent homedir:

0 dkg@alice:~$ HOME=/nonexistent gpgconf --list-options gpg-agent
gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
gpgconf: fatal error (exit status 1)
1 dkg@alice:~$

This has the result of producing spurious warning messages for things like cronjobs that run as the user nobody, in situations where the system has some scripts that are expected to run at every user session that rely on gpgconf to determine what to do about the agent.

gpgconf should be robust enough that system-wide per-user scripts can run it without worrying about this kind of error. Otherwise, people are going to write system-wide per-user scripts that guess at GnuPG's configuration and behavior, rather than interrogating GnuPG's configuration through the preferred interface. That would be a bad outcome because all of those scripts would need to be updated if GnuPG's configuration and behavior were to change.

Details

Version
2.2.19

Event Timeline

As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.

Sure, I personally know that GnuPG requires a homedir to operate.

The question is what do you want a system-wide script to do when it's trying to do something conditionally based on some expected configuration from gpg? Should it use gpgconf to query for that value, or should it wrap that query in some custom (and maybe broken) test? If it's possible for gpgconf to be more robust and to emit sensible answers even in situations where GnuPG might have problems, that seems like the better option.

It's not clear why the read-only forms of gpgconf should need to have write access to the homedir. if the configs don't exist, isn't there default output that could be produced?

I t could print a warning for a non-existant homedir

werner claimed this task.

[These damned typos in commit messages ;-)]

Should be fixed now for 2.2.22 and the forthcoming 2.3;