AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"
Fiedler Roman
Roman.Fiedler at ait.ac.at
Wed Sep 5 16:29:16 CEST 2018
> Von: Peter Lebbing [mailto:peter at 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
More information about the Gnupg-users
mailing list