When "use_keyboxd" is configured --keyring option is ignored?
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	janl
	Aug 22 2024, 10:12 AM

Description

We have a tool for password management that uses the --keyring option to access the tools own keyring.

When a new team member installed gnupg and generated his keys gnugp wrote a common.conf with use_keyboxd. As long as this line is in the common.conf file this command will only list the public keys in the keybox and not in the specified .keyringy file:

gpg --no-default-keyring --keyring=./.keyring -k

which is a bit surprising. I think that when --keyring is specified it should (also?) list the public keys in the .keyring no matter if use_keyboxd is specified.

gpg 2.4.5 installed with brew on a mac.

gpg (GnuPG) 2.4.5
libgcrypt 1.10.3
Copyright (C) 2024 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/elvin.baloku@schibsted.com/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Thanks!

Details

Version: 2.4.5

Revisions and Commits

rG GnuPG
	rG92667aa8c208 gpg: Warn if a keyring is specified along with --use-keyboxd.
	rG3171ca9b949b gpg: Warn if a keyring is specified along with --use-keyboxd.

Related Objects

Mentioned In: T7527: Keyring/keybox denial of service
Mentioned Here: T3464: successful decryption with session key reports failure if public key is unknown

Event Timeline

janl created this task.Aug 22 2024, 10:12 AM

The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

The long standing suggestion for using a separate set of keys is to use a different GNUPGHOME. The problem with adding and removing a keyring is that other meta information are hold in other files and things get messed up if parts of the GNUPGHOME are modified. Thus use

GNUPGHOME=/mytools/home/gnupg  gpg foo

and you have full control over everything. In case you are concerned about stopping the gpg-agent or otehr background prosesses you may shut them down with

GNUPGHOME=/mytools/home/gnupg gpgconf -K all

Obviously you should export GNUPGHOME or you can start your software like this

GNUPGHOME=/mytools/home/gnupg gpg-agent --daemon /foo/bar/myownshell

which has the advantage that when myownshell terminates gpg-agent and other dameons are shutdown as weel after a couple of seconds.

Right, thanks for the information. Might I suggest printing a warning when --keyring is given?

Thanks again!

• werner added a commit: rG3171ca9b949b: gpg: Warn if a keyring is specified along with --use-keyboxd..Aug 23 2024, 9:19 AM

Good idea. Done for master and gnupg24

• werner added a commit: rG92667aa8c208: gpg: Warn if a keyring is specified along with --use-keyboxd..Aug 23 2024, 9:21 AM

This warning doesn't seem to be complete; no such warning is produced on the first run of gpg. For example (with no ~/.gnupg):

0 dkg@bob:~$ gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg  --list-keys
gpg: directory '/home/dkg/.gnupg' created
gpg: /home/dkg/.gnupg/trustdb.gpg: trustdb created
0 dkg@bob:~$ gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg  --list-keys
gpg: Note: Specified keyrings are ignored due to option "use-keyboxd"
0 dkg@bob:~$

In both cases, gpg returns 0 (conventionally used to mean "success") and produces no output. In only one case does it produce a warning.

If --keyring is generally deprecated, then i think the warning should be emitted on *any* use of --keyring. And if it is a no-op when use-keyboxd is present in $GNUPGHOME/common.conf, then it should produce an error, not merely a warning. Otherwise, when used within a script or a GUI where gpg's stderr is not easily accessible to the user, it might be ignored entirely. No warning is emitted on stdout, or on the status file descriptor, for example, which replicates the way that scripted use generally happens:

0 dkg@bob:~$ gpg --batch --status-file /tmp/gpg.status --with-colons --keyring /usr/share/keyrings/debian-archive-keyring.gpg  --list-keys > /dev/null
gpg: Note: Specified keyrings are ignored due to option "use-keyboxd"
0 dkg@bob:~$ cat /tmp/gpg.status 
0 dkg@bob:~$

The above examples are made using 2.4.7.

Won't be fixed for the creation thing.

I understand you as saying you won't fix the fact that the warning is not emitted during initial homedir setup. I'm not sure why that scenario is not worthy of a warning when a post-setup scenario is, but okay.

Do you also intend to not address how this is likely to cause bugs in scripts or graphical tooling that either hide stderr from the user or mix it in with a stream of other noisy stderr messages? How are these programmatic uses supposed to know that there has been a change in configuration?

Should --no-keyring also emit a warning when use-keyboxd is in use? its behavior appears to change as (for example) gpg --no-keyring --list-keys actually produces output when use-keyboxd is present in common.conf.

gpgme itself uses --no-keyring in certain contexts (when decrypting via session key but not verifying signatures, see T3464).

Are there any tests for any tool that uses gpgpme on a homedir configured with use-keyboxd while it decrypts with a session key without verifying?

dkg mentioned this in T7527: Keyring/keybox denial of service.Mon, Feb 10, 10:31 PM

That is an installation/migration question and the warning is just a convenience thing to remind the few early users of keyboxd to migrate to common.conf.

I'm not going to keep re-opening a ticket that you keep closing. So i'm just going to state here what i believe to be the upstream intent is. If you think this is wrong, i'd love a clarification. I believe that "deprecated" means that the GnuPG project believes that an option or configuration choice should not be used, and will eventually go away.

the following options are deprecated: --keyring, --no-default-keyring, --no-keyrings, --primary-keyring, --secret-keyring.
the deprecations are not explicitly stated in the manpages or other documentation.
when the options are present, sometimes they modify the output or logic of gpg, and other times they do not (e.g. depending on the presence of use-keyboxd in common.conf)
gpg only warns (via a single line to stderr) about the use of these options in some cases: only when use-keyboxd is in effect, but not all the time when use-keyboxd is in effect, and not all deprecated options get a warning even in this case.
when use-keyboxd is present, these options are effectively disabled (treated as a no-op, but this disabling produces no warning that would be readable by automated tooling (e.g. the --status-fd), and are not rejected as an invalid configuration choice (the way gpg without keyboxd would reject, say, --keyring /does/not/exist)

The current state of 2.4.7 shows that the presence or absence of use-keyboxd even affects the return code of gpg. Traditionally, --keyring produced an error if the keyring could not be read for whatever reason. But with use-keyboxd, *all* --keyring options cannot be read (because it's not trying to read them), and yet they do *not* produce an error:

0 dkg@bob:~$ find $GNUPGHOME -ls
   652607      0 drwx------   2 dkg      dkg            40 Feb 11 09:57 /tmp/gg
0 dkg@bob:~$ gpg --keyring /does/not/exist --list-keys
gpg: keybox '/tmp/gg/pubring.kbx' created
gpg: keyblock resource '/does/not/exist': No such file or directory
gpg: /tmp/gg/trustdb.gpg: trustdb created
2 dkg@bob:~$ echo use-keyboxd > $GNUPGHOME/common.conf
0 dkg@bob:~$ gpg --keyring /does/not/exist --list-keys
gpg: Note: Specified keyrings are ignored due to option "use-keyboxd"
0 dkg@bob:~$

All of the above looks like a suboptimal deprecation strategy to me.

For deprecating a command line or configuration option in a long-standing tool, i prefer an approach that goes more like this (in temporal order):

Update all documentation to indicate that the option is deprecated, and the recommended alternate method for a user who wants that functionality.
Produce a warning whenever the option is used, even if it is still effective. The warning can point to the documentation from the prior step.
If the option is being set from a configuration file, offer an easy, automated way to remove that option from the configuration file.
If some newer option is incompatible with the deprecated option, then whenever the newer option is used in conjunction with the deprecated option, produce a hard error in addition to the warning. Do not perform any operations in such a contradictory state.
Finally, hard reject the deprecated option, regardless of whether an incompatible option is present.

Typically I would expect a significant amount of time (and a major version number) to elapse between the last two steps.

I don't think GnuPG is serving its userbase well with the approach it has chosen.

Where do you find a statement that --keyring is deprecated? I planned to to remove it with 2.1 but there were too many requests to keep it and live with the problems of multiple keyrings. Thus the option stayed, it is just so that in addition to pubring.gpg and pubring.gpg we now also have the option for keyboxd - which is the default for new installations.

I was referring to your comment earlier in this very issue:

The --keyring option is deprecated and does not work at all if the keyboxd is used.

Perhaps you were trying to say here that it is only deprecated when keyboxd is used. that is: "(deprecated and does not work at all) if the keyboxd is used".

But that is not the usual meaning of the term "deprecation". An option or control path that does not work at all is not "deprecated", it is "disabled". So i read this in the more natural way of "deprecated and (does not work at all if the keyboxd is used)"

If you're saying that the option is not deprecated when keyboxd is not used, then i don't know what that even means. As i understand it, the point of a deprecation is to phase out the use of a control path in an orderly and predictable way with minimal disruption. How is any tooling that wraps gpg supposed to act on such a deprecation, given that it will typically not know whether keyboxd is used or not?