Implications of a common private keys directory in 2.1
Stephan Beck
stebe at mailbox.org
Mon Dec 12 18:20:00 CET 2016
Carola Grunwald:
> Peter Lebbing wrote:
>
>> On 11/12/16 20:58, Carola Grunwald wrote:
>>> With 'problems' i referred to the GenKey bug/feature I reported a few
>>> hours ago and the IPC instabilities I experienced. Sure, the
>>> single-sec-keys-depository : multiple-pub-keyrings configuration is a
>>> design decision, though one I don't quite understand.
>>
>> Oh, I thought you were referring to my warning that running the agent
>> with lots of private keys might hit some unforeseen issues.
>>
>>> You mean --try-secret-key doesn't overrule the key parameter that comes
>>> along with the encoded material?
>>
>> No, it specifies which keys to try for a hidden recipient. This is easy
>> to investigate if you create a few test private keys and create some
>> test messages. I did that earlier, and I could see no overruling
>> behaviour or even a preference to --default-key or --try-secret-key.
>
> You're right, unbelievable. I specify --try-secret-key with a
>
> [GNUPG:] ENC_TO 0000000000000000 18 0
>
> message and gpg still tries out two dozen WME keys with a passphrase not
> valid for them. What a waste of time!
If you knew the cacheIDs of all cached passphrases you could use
"2.6.8 Remove a cached passphrase
--------------------------------
Use this command to remove a cached passphrase.
CLEAR_PASSPHRASE [--mode=normal] <cache_id>
The '--mode=normal' option can be used to clear a CACHE_ID that was
set by gpg-agent."
for removing all passphrases but one (the one you would like to be used).
If you'd want to make sure that the right passphrase is provided, why
don't you use --pinentry-mode loopback
"Use a loopback pinentry. This fakes a pinentry by using
inquiries back to the caller to ask for a passphrase."
Sorry, I can't reproduce your environment for now and only have these
"dispersed notes" exposed here (but found your description of your
system very instructive and largely followed it). I merely point you to
options the usefulness of which you are more experienced to assess.
Cheers
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161212/f7d17189/attachment.sig>
More information about the Gnupg-users
mailing list