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.