> Von: Peter Lebbing [mailto:pe...@digitalbrains.com] > > On 05/09/18 10:45, Fiedler Roman wrote: > > * Decrypt and verify with gpg1 on receiver side: > > > > /usr/bin/gpg1 --no-options --homedir Receiver --no-default-keyring -- > keyring Sender/SenderKey.pub --lock-never --trust-model always --batch -- > display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets < > Sender/OutgoingMessage.gpg > > If you want to know which of the public keys you have signed a > particular message, instead of restricting your "keyring" to a single, > desired key, you can scan the status-fd for > > [GNUPG:] GOODSIG <long_keyid_or_fpr> <username>
That would be the preferred way if each recipient has and is allowed to have a list of public keys. As in my usecase the keys are stored in a database and only the relevant key is handed out by a service, used for the operation and then thrown away again. In a perfect world it should never touch non-volatile storage during that process. Not relying on a local keyring to be filled should also allow central sanitation/quality assurance of encoded public key material, thus avoiding security issues on status-fd protocol with key fields similar to filename related problems in gnupg (see CVE-2018-12020) Apart from that, is not the [GNUPG:] VALIDSIG 25CE8B1D52A5B231543F8D660EE7BE094144A67F 2018-09-05 1536157493 0 4 0 1 8 00 25CE8B1D52A5B231543F8D660EE7BE094144A67F more suited for checking? The 64-bit key-IDs should be close to bruteforcing, thus not really reliable for key identification? > In this case, just keep your keyring as it normally is, containing all > public keys. You might then also reach a situation where you can > meaningfully use a trust model, instead of your --trust-model always. > > status-fd is documented in doc/DETAILS. The "--status-fd" is really great for that to pin keys in a classical setup, where I have such filter lists already in operation. Regards, Roman _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
