Page MenuHome GnuPG

--trusted-key and --no-options mismatch
Testing, NormalPublic


There is an annoyance in the code to handle the trusted keys option: If the gpg.conf has trusted-key options those trusted keys will be marked in the trustdb for a more uniform access. This is done used a flag in the trust records. With each invocation of gpg, involving trust computation, the state of the trusted-key options is synced to the state of the trustdb. For example if there is a new trusted-key in the config, this will cause an update/insert of a trust record so that the next trust computation can make use of this new ultimately trusted key. If a key is removed from the config, the trustdb is also updated to known trust for this key.

Now, at some places (e.g. gpg-wks-client) gpg is run internally using the --no-options options. This will effectivly remove the the trusted key for this operation. With the next regular run of gpg it will then be re-added. This is highly ineffective and may also leads to inconsistent view of the key validity.

A proposed fix for this is not to sync the trustdb iff --no-options is used. Implementation wise - and also to cope with a /etc/gnupg/gpg.conf - the presence of any trusted-key option could trigger this.

Event Timeline

werner triaged this task as Normal priority.Mar 4 2024, 1:45 PM
werner created this task.

How to test:

Create a signing key, sign some keys, set the trust for the signing key back to undefined and instead put the key as trusted-key into the gpg.conf. Then run

gpg -K >/dev/null

to sync the trustdb. (A lot of other commands will do that too). Now a

gpg --list-trustdb | grep ', trust ' | grep -v f=00

will show the the signing key with f=01 indicating that it has been entered via trusted-keys and not directly marked as ultimately trusted (which is the case for new keys). Next run

gpg --no-options -K >/dev/nul

and check check again with the--list-trustdb that you see the same output. Without the fix you should not see the line with f=01. Note, you may also add -v to the gpg invocation to tell something about the syncing.

werner changed the task status from Open to Testing.Mar 4 2024, 3:24 PM
werner moved this task from Backlog to WiP on the gnupg22 board.