--export-options export-reset-subkey-passwd in gpg 2.1.x

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Oct 9 18:26:03 CEST 2014

On 10/09/2014 02:13 AM, Werner Koch wrote:
> On Thu,  9 Oct 2014 01:31, dkg at fifthhorseman.net said:
>> It's not clear to me what the "specialized secret key export tool" is --
>> does this tool exist or is it hypothetical at the moment?
> Hypothetical.  I guess I was only too lazy to implement that given that
> I only had the use case in mind for which I created it.

ok, that makes sense.

> The real problem is that we can't export with a passphrase right now.
> gpg-agent would need to be extended to export the key without a
> passphrase.

This is a bit confusing, but it makes sense if i read the first sentence
as "without a passphrase" instead of "with a passphrase" -- is that
right?  certainly when i look at the output, the exported secret keys
are indeed encrypted.

It's also a little weird to me that i get prompted for my key's
passphrase when i do "gpg2 --export-secret-subkey 0x${SUBKEYID}\!"

if the emitted key is passphrase-locked already, then why do i need to
provide my passphrase in the first place for the export?

from monkeysphere's perspective, i'd prefer to just reinstate the
export-reset-subkey-passwd directive, to maintain compatibility.

Would you be open to a patch that does that for 2.1?  I'd be fine if it
only works for --export-secret-subkey when the subkey is specified

>>   -c (require confirmation -- gpg-agent accepts but does not honor this flag)
> This used to work but I have not tested it recently:
>       prompt = xtryasprintf (_("An ssh process requested the use of key%%0A"
>                                "  %s%%0A"
>                                "  (%s)%%0A"
>                                "Do you want to allow this?"),
>>   -d (delete key -- gpg-agent accepts but does not honor this flag)
>>   -D (delete all keys -- gpg-agent rejects this flag with an error)
> Indeed the semantics are different: gpg-agent stores the key permanently
> and thus all keys are always available.  The passphrase chaching comes
> on top of it.
>>   -t N (limit key lifetime to N seconds -- gpg-agent accepts but does not honor this flag)
> That could be translated into: store a default caching time for ssh use
> with that key.  For example by putting that into ~/.gnupg/sshcontrol
>>   -x (lock agent with password -- gpg-agent accepts but does not honor this flag)
> Doesn't match the way gpg-agent works.

To be clear, i'm not proposing that we should implement all of these
things in gpg-agent -- ssh-agent works for me and matches the workflow
that i expect.  And i know how you feel about agents hijacking other
agents when their semantics and operational behaviors are different :)

i just want to be able to keep my current work habits while moving to
the newer GnuPG. :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141009/95e4d2f8/attachment.sig>

More information about the Gnupg-devel mailing list