in gpg 1.4.x and 2.0.x, "gpg --batch --export-secret-key" would emit an unlocked
secret key if the stored key had no password.
With GnuPG 2.1.11, the agent will prompt the user to add a passphrase to the key
before export, even if gpg had been invoked with --batch.
This causes scripts which use --batch to fail in the situation where no
passphrase is set on the key.
furthermore, if the user enters an empty password, gpg-agent says "please
confirm that you do not want to have any protection on your key".
If the user chooses "yes, protection is not needed" in this followup prompt, gpg
*still* refuses to export the secret key, producing this error message:
gpg: key 0CA2C754F8DF3194EC1F1C7EF88AEA8D20BAFB0F: error receiving key from
agent: No passphrase given - skipped
Ok, so there are two problems:
passphrase.
Werner, I started patching gpg-agent to allow 2., but gpg does only accept
protected keys from gpg-agent in export.c's transfer_format_to_openpgp. Is that
by design or simply not yet implemented?
I have some stashed work to fix this but it is not ready - let me know if you
want to work on it.
re: T2324 (justus on Apr 18 2016, 05:22 PM / Roundup)
That would violate the policy we implement in gpg-agent. The
gpg-agent is responsible for private keys and a client may not use a
private key without the agent's consent. If we would allow that by
default there won't be any protection at all and keys can be easily
exported and used. A required confirmation via the Pinentry would
solve the practical problem. However, there is the question what to
do on unattended systems - the only way it can be done right now is
configuring gpg-agent to use a custom pinentry, or by extending the
loopback mode.
I'm not convinced that this policy is effectively implemented in gpg-agent.
The patch series that starts here:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031121.html
resolves the export of secret key material stored as cleartext, and it does so
without modifying gpg-agent at all.
fwiw, I do not agree with T2324 (justus on Apr 18 2016, 05:22 PM / Roundup) that gpg --batch should not use pinentry at
all -- i think it's quite useful to be able to combine --batch with pinentry,
where the key is stored protected, or is otherwise marked by gpg-agent for
limited use.
dgk: You are right that Pinentry may be used even with --batch. In fact gpgme
uses --batch and a Pinentry is used nevertheless.
Right, there are no technical means right now to inhibit the export of private
keys. However, it would be easy to add this by not allowing gpg-agent to tell
the client the key used to encrypt the import/export command of keys.
A user migyt have used no passphrase for a key in the believe that an
unprotected key can't be exported.
The question at hand is whether dkg's patch or Justus work is the way to go. I
have not yet reviewed dkg's patch, though.
I did not work on this other than what I merged. What I did is to enhance our
fake pinentry program to allow it to supply different passphrases, make it write
a log so that we can quantify the pinentry interaction in test cases, and to add
an export test documenting the status quo.
I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.
Hi,
the 2.1.13 announcement has
"""
"""
(from https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html)
so this defect may be fixed with 2.1.13 I guess, cool!
Probably only need a test to confirm?
I'm using latest master and I still can't export a secret key without passphrase.
And Justus also has not closed this bug or wrote that he commited something
more. So I think the 2.1.13 announcement was mistaken and this problem still
exists. (Or am I missing some option / need a different pinentry mode?)
So i've tested this locally with:
export GNUPGHOME=$(mktemp -d)
gpg --quick-gen-key 'test user <test@example.org>'
gpg --armor --export-secret-key 'test user <test@example.org>'(choosing no passphrase during the prompts that come up during the quick-gen-key
step). The final export step works fine.
Can you show what steps you're taking that fail for you, Andre?
Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.