Implications of a common private keys directory in 2.1

Stephan Beck stebe at mailbox.org
Wed Dec 7 12:47:00 CET 2016



Peter Lebbing:
> On 06/12/16 15:53, Stephan Beck wrote:
>> [...], and use it as in
>> gpg2 --no-default-keyring --secret-keyring file --try-secret-key
>> [NAME=aspecificlongKeyID | fingerprint] --decrypt
>> any_signedANDencrypted_message.txt.gpg ?
>> Would that work?
> 
>>From the GnuPG 2.1 man page:
> 
>        --secret-keyring file
>               This is an obsolete option and  ignored.   All  secret  keys  are
>               stored  in the ‘private-keys-v1.d’ directory below the GnuPG home
>               directory.
> 
> GnuPG 2.1 works in a different way with secret key material, so you can't have multiple secret keyrings in the same homedir anymore.

Oh, I missed this point. Thanks for putting it right. And it's more, no
code left in gpg 2.1 for handling (secret) key material. Another mistake
is (from what I have learned now) that you can only apply
--try-secret-key together with --hidden-recipients.
Anyway, if there was an "!" option as in --export-secret-subkeys keyID!
you would be able to indicate/convince/force gpg 2.0.x to use a
particular (sub)key. But I think this only refers to the case of having
several subkeys, and at the moment of exporting one of them. And it's a
2.0.x option, I haven't checked the 2.1 manual for this particular
option yet, though.

Thanks

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x4218732B.asc
Type: application/pgp-keys
Size: 4089 bytes
Desc: not available
URL: </pipermail/attachments/20161207/26bf1099/attachment.key>
-------------- 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/20161207/26bf1099/attachment.sig>


More information about the Gnupg-users mailing list