Implications of a common private keys directory in 2.1

[Carola Grunwald]

Stephan Beck wrote:
>Carola Grunwald:
>> Stephan Beck wrote:
>>> Carola Grunwald:
>>>> Peter Lebbing wrote:
>> 
>>
>> Removing all cached passphrases sounds great. But does that mean I have
>> to invoke the agent directly using the Assuan protocol? And what would
>> be the way to get a list of all valid cache_ids?
>
>well, now as you explained it again (below), and rethinking the whole
>issue, the use of this command does not let you get any closer to a
>solution, so I haven't investigated it further.
>> 
>>>
>>>
>>> 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."
>> 
>> That's what I actually do:
>> 
>> | G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906"
>
>Wouldn't you have to add, differing from version 1.4, the --batch option
>when using --passphrase string with gpg2.1?

Obviously not (see 'INQUIRE PASSPHRASE' below).

>
>> 
>> There's the id of a secret key with its passphrase, but if decoding
>> doesn't succeed with that key-passphrase combination or if the key
>> doesn't exist there are decryption attempts with all other secret keys
>> in the private-keys-v1.d folder, which only waste time:
>> 
>> | [GNUPG:] ENC_TO 0000000000000000 18 0
>> | [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one
>> | [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0
>> | [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0
>> | [GNUPG:] KEY_CONSIDERED ...
>> 
>> AFAICS it always uses the same given passphrase with all the keys, which
>> is good:
>> 
>> | gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE
>> | gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM
>> 
>> What I need here is the restriction to just the given key.
>
>And the agent's SETKEY command?
>gpg-connect-agent
>> help SETKEY
>SIGKEY <heystring with keygrip>
>SETKEY <hexstring with keygrip>
>Set the key used for a sign or decrypt operation.

Isn't there a gpg SETKEY option for decryption? AFAICS --default-key is
only for signing, --recipient for encryption. Is --try-secret-key the
SETKEY equivalent for decryption? Can a developer shed light on this?

Kind regards

Caro