Page MenuHome GnuPG

GnuPG 2.1 regression in unattended key generation
Closed, ResolvedPublic

Description

GnuPG 2.1.11 seems to have a regression with unattended key generation, as first
described on Stack Overflow [1]. Earlier versions allowed writing the secret key
to a special file (I verified against GnuPG 1.4.20). Probably as some side
effect of merging the secret keyring into the public one, the %secring
statement does not work any more, the secret key is not written at all (neither
to the default GnuPG home directory, nor to foo.pub, nor to the specified
foo.sec. Omitting %pubring results in the (public and secret) key being
written to the default home directory's keyring.

    [snip]
    %pubring foo.pub
    %secring foo.sec
    %commit

The option is still documented for GnuPG 2.1 [2].

Possible solutions:

  • Actually write the foo.sec file
  • Add a new configuration option "include secret key in public keyring" and

remove the %secring option from the documentation

[1]: http://stackoverflow.com/q/37936393/695343
[2]:
https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

Details

Version
2.1.11

Event Timeline

That is not easy to change. By design gpg-agent generates the key and does not
return it (except for a hack to support --export-secret-key).

2,1 has the goal to replace 1.4 and thus I see the need to support creating a
key w/o string it in private-keys-v1.d/.

If this is unsupported by GnuPG 2.1 and unlikely to change, at least the
documentation should be updated.

The only viable solution will be to export the key secret key after key
generation, append that to the %secring given file and delete the key from
gpg-agent's store. Recall that the agent needs to know the secret key so that
gpg is abale to create the self-signatures. Adding a dedicated cache for this
would complicate the gpg-agent code a lot.

I'm going to write some documentation about the programmatic use of GnuPG.