Page MenuHome GnuPG

gpgconf lists options which break gpg1 when gpg2 is also installed
Closed, ResolvedPublic


gpgconf advertises options that, when used, break the old version 1 gpg. An
example is the log-file option announced by "gpgconf --list-options gpg": The
option is not supported by the old gpg, but still GUIs relying on gpgconf offer
to set it. After doing so, every operation of gpg fails since it complains about
an invalid option in the gpg.conf file. IMHO this is unacceptable and a bug GPG
(and not the GUIs), since gpgconf was used exactly the way it was intended. As
an example, have a look at [1].

If a co-installation of gpg1 and gpg2 is supported, this should be fixed either
by gpgconf using ~/.gnupg/gpg.conf-2 for such options or by letting gpg1 ignore
these options.




Event Timeline

ralf added projects: gnupg, Bug Report.
ralf added a subscriber: ralf.

Gpgconf uses the configuration file as advertised by gpg.
For example:

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:

  $ touch ~/.gnupg/gpg.conf-1

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:

Thus you only need to create a gpg.conf-1 (or conf-2) and you are
done. This is an installation problem.

werner lowered the priority of this task from High to Normal.
werner removed a project: Bug Report.

Of course it can be fixed by changing the config files. However, the default
behaviour (if I start gpgconf as a new user) is to use the shared config file
for both versions. As I see it, programs are responsible to set up the
configuration in the user's home directory if they need one - at least, that's
common practice in my experience.
If this is not a bug in GnuPG, then whose installation problem is this?

The one who decided to install both versions while at the same time using an
option not available for gpg1. It might be caused by a package manager.

So you are saying, every distribution supporting a co-installation should patch
GPG to fix this?
The user might not even know what gpg is, that several major versions exist, or
which options are available where. He just sees email encryption not working any
longer. In most cases, he won't have decided to install both versions - he just
has software installed which, indirectly, depends on both.

bernhard renamed this task from gpgconf lists options which break gpg to gpgconf lists options which break gpg1 when gpg2 is also installed.Apr 18 2013, 8:53 AM
bernhard reopened this task as Open.
bernhard added a project: Bug Report.
bernhard added subscribers: bernhard, aheinecke.

I agree with Ralf that we need a solution for this.
I can be a multi-step solution.

But right now, most GNU distributions are not putting much effort in
the GnuPG installation and setup help. For example: With Debian squeeze
you cannot deinstall gpg1 because the dependencies would drag down other
software. Yes, this is partly a packaging problem with should be solved on
Debian's side (as well), but if we want GnuPG to be successful we need to offer
users and packagers best practice and clear recommendations.

My suggestions:
a) Make the suggestions more clear that gpg2 only should be recommened only in
almost all installations
b) offer some safety nets if there are both installed and gpgconf is used.

Actually we have a solution here since 1.4.13: For example if the conflicting
option is "foo-me", you would put this line into gpg.conf:

ignore-invalid-option foo-me

and gpg will silently skip that option. Of course you need to put the above
line before the line with foo-me.

This has not yet been announced to avoid abuse but if at anytime in the future a
real problems pops up, we will have a workaround already deployed.

Real problems have already popped up years ago:

So gpgconf could add, for example, "ignore-invalid-option log-file", to the
configuration file if a log-file option is emitted, and then GnuPG2 would still
honour this option, but GnuPG1 would silently ignore it?

Well my suggestion would be that gnupg reads configuration values from
gpg.conf-version AND gpg.conf so that one could keep common options in gpg.conf
and write version specific ones to gpg.conf-version.

But with the ignore-invalid-option option we can at last fix this from the KDE
side. Werner do you have any idea how one can get the list of supported options
from gpg 1 in a reliable way? So that one could check which options are
supported by gpg1 or will there be no options added to gpg1 in the future?

No, that is way too complex and will easily lead to a combinatorial explosion.
Both versions should not be installed on a standard system. For migration
purposes this is possible but it should always be viewed as an exception.
gpgconf shall never do that. If there is a problem, the user/admin needs to fix
it. I wish we never had introduced those version specific conf files.

Andre: "gpg --dump-options" is supported for 15 years or so and thus an easy way
to figure out which options are available.

I strongly suggest to have an official recommendation how to solve this issue.
The currently available information does not help packagers and application
developers enought to get it right. Probable most distributions should prevent
gpg1 and gpg2 to be installed with their dependency handling.

werner reopened this task as Open.
werner closed this task as Resolved.

Werner, you closed this issue with (the now removed) T1448 (wk on Jun 24 2014, 01:42 PM / Roundup) stating:
"You may use --ignore-invalid-option to list options which are only implemented
by gpg2."

This option seems only to be supported in gpg.conf, not on the command line.
(but this is no problem for me)

And it generally works fine (thank you!), just not in this special case here,
becaue gpg1 accepts the option "--debug-level" as valid, but does not allow
any arguments (neither numbers nor e.g. "basic").

The result (with "debug-level basic" in line 42) is:

$ gpg
gpg: /home/thomas/.gnupg/gpg.conf:42: argument not expected

I'm currently using gpg (GnuPG) 1.4.18 from Debian jessie.

As I understand it, "debug-level" is intended to just be a dummy option in
gpg1 to avoid problems with this option appearing in gpg.conf, correct?
So we have two possible solutions:

  • either remove option "debug-level" (and rely on "ignore-invalid-option debug-level")
  • or accept an argument for "debug-level"

gpgconf, which is a gnupg 2 tool, can't work with gpg version 1. As soon as you
use options not available in gpg 1 you will run into problems for which there
may or may not be a workaround.

The easy workaround is to use gpg.conf.1 which will be used by gpg 1 instead of

Just for the record:
It's gpg.conf-1 or gpg.conf-2 and not gpg.conf.1

My workaround for this problem also was to have a gpg.conf-2 which is then used
by gpgconf and a gpg.conf that is used by gpg 1.

Sorry, I have not used those conf files suffixed for a long time.

Solution has been given: Use "gpg.conf-1" for gpg 1.4