Home GnuPG
Diffusion GnuPG eae28f1bd4a5

doc: Remove profile and systemd example files.

Description

doc: Remove profile and systemd example files.

The profiles are not any longer useful because global options are way
more powerful (/etc/gnupg/gpg.conf et al.). The use of systemd is
deprecated because of additional complexity and the race between
systemd based autolaunching and the explicit gnupg based and lockfile
protected autolaunching.

Event Timeline

The profiles are not any longer useful because global options are way more powerful (/etc/gnupg/gpg.conf et al.).

How are distros supposed to set a value for pinentry-program now? gpg-agent only looks for the config in the user directory and fails to find pinentry if it is not in PATH.

Use a symlink or the alternatives systems. The --pinentry-program option was introduced for debugging.

I was asking because the question came up on NixOS and how we handle this, for us, breaking change.
We don't have a global PATH we could necessarily symlink into but a wrapper could work. NixOS also does not use the alternatives system at all because it wouldn't work well with the distro design.

I am wondering why the global configs are not for all config options and for all of the various config files. That would make things for us and in general a lot easier. Also that the pinentry-program options was only for debugging was not obvious to us but we might continue to use it to avoid unnecessary wrappers around or symlinks.

The profiles are not any longer useful because global options are way more powerful (/etc/gnupg/gpg.conf et al.).

How are distros supposed to set a value for pinentry-program now? gpg-agent only looks for the config in the user directory and fails to find pinentry if it is not in PATH.

gpg-agent (I tested 2.4.something) looks at /etc/gnupg/gpg-agent.conf according to strace. I'm not sure why you think it doesn't, but maybe your older version really doesn't.

Frankly, I don't understand the problem. Without the pinetry-program option you have a ./configure option to set the name of the pinentry. If you don't use that gpg-agent looks for $bindir/pinentry and if not found for $bindir/pinentry-basic.

gpg-agent (I tested 2.4.something) looks at /etc/gnupg/gpg-agent.conf according to strace. I'm not sure why you think it doesn't, but maybe your older version really doesn't.

NixOS is usually using up to date software and we are already on 2.4 but we have sysconfdir configured to the package install path, not /etc/gnupg. Thats on our side.

Frankly, I don't understand the problem. Without the pinetry-program option you have a ./configure option to set the name of the pinentry. If you don't use that gpg-agent looks for $bindir/pinentry and if not found for $bindir/pinentry-basic.

NixOS is not a classical distro that just installs all packages into /bin/, /usr/, etc. Each package has it's own store path where it gets its own directory. From there it gets loaded via symlinks, envs, config entiries, etc.
We don't want to compile one gnupg for each desktop environment to have it hardcoded relative to gnupg but make it configurable depending on the DE used. As a fallback we could just symlink together gpg and the right gpg-agent which is rather cheap.

We don't want to compile one gnupg for each desktop environment to have it hardcoded relative to gnupg but make it configurable depending on the DE used. As a fallback we could just symlink together gpg and the right gpg-agent which is rather cheap.

Don't do that. gpg and gpg-agent should be used from the same build. There is an internal API which we try to keep as stable as possible but tehre is a reason why we print a warning if an older gpg-agent is used.

If you don't want a /etc/gnupg and don't want to symlink it - you will run into problems.

BTW, there is a gpgconf.ctl file which you can install along to gpgconf and use it to runtime configure some directories. Example from the test suite:

# gpgconf.ctl.in - copied to bin during tests.
#
# This file is used to change the directories where the gpg components
# are installed.  It does not change the configuration directories.
# The file is expected in the same directory as gpgconf.  The physical
# installation directories are evaluated and no symlinks.  Blank lines
# and lines starting with pound signed are ignored.  No errors are
# printed for unknown keywords or commands.  The only defined key for
# now is "rootdir" which must be followed by one optional space, an
# equal sign, and the value for the root directory.  Environment
# variables are substituted in standard shell manner, the final value
# must start with a slash, trailing slashes are stripped.

# This file is only considered if the given envvar evaluates to true.
.enable = $GNUPG_IN_TEST_SUITE

sysconfdir = $GNUPG_BUILD_ROOT/etc
rootdir = $GNUPG_BUILD_ROOT/

See gnupg/common/homdir.c:unix_rootdir .enable is optional and really only required by the test suite.

I am wondering why the global configs are not for all config options and for all of the various config files. That would make things for us and in general a lot easier. Also that the pinentry-program options was only for debugging was not obvious to us but we might continue to use it to avoid unnecessary wrappers around or symlinks.

This makes me think that you might have looked at gpgconf.conf and not the current iteration of the global options where we have support for all options and config files. I find the global Options to be ideal, if this is not suitable for your usecase we should make an issue out of it because that should IMO be the case. For what it is worth I would also disagree with the statement that pinentry-program is only used for debugging.

Sorry to bump a discussion a few months after it has already died down, but with the deprecation and removal of init-based supervised launching of gpg-agent, what's the recommended approach now to auto-start it?

To be more specific in my case, I am using a custom $GNUPGHOME set by ~/.bash_profile along with a custom pinentry program added to my PATH. With this in mind, what would be the best approach with which to start gpg-agent automatically and ensure it follows a specified home directory?

Well, it Just Works(tm). You should make sure that a /run/user/NNNN direcory exists so GnuPG is able to create its subdir for the socket files.

gpgconf -L might be helpful to see what direcories are actually used. GNUPGHOME must be set of course and exported.