gpg --import of secret keys prompts for passwords in 2.1
Open, NormalPublic

Description

In gpg 2.1, if a user imports a secret key file that contains a locked key, they
get prompted by the agent for the password for that key. Failure to enter the
password for the key (or failure of pinentry, etc) results in no keys imported,
and a termination of the entire import afaict (further secret keys are not
imported).

However, if the user uses --batch --import, or if gpg is just migrating their
existing secring.gpg, the keys are imported silently, and their passphrases are
left unchanged.

It's not clear to me what the advantage is of prompting for the passphrase upon
import.

Even if there is a reason to prompt for the passphrase, it's not clear that a
failure to enter the passphrase correctly (or a failure to launch pinentry)
should abort the import, instead of proceeding as --batch or as the normal
migration proceeds.

I think the simplest thing to do is to not prompt for the passphrase upon import
at all, and just place the secret key directly into ~/.gnupg/private-keys-v1.d

Details

Version
2.1
dkg added a subscriber: dkg.
werner added a subscriber: werner.Apr 15 2016, 8:38 AM

The reason for prompting for the passphrase is that gpg/gpg-agent needs to
re-encrypt the key to the format used by gpg-agent. Although the format is
currently very similar it is not a 1-to-1 mappring and thus it needs to be
re-encrypted. Further the S2K "iteration" parameter used by gpg-agent is to be
adjusted to the speed of the new machine.

The kludge we use with --batch is to allow fast migration of keys from older gpg
versions to to 2.1. This works by storing the secret key directly in the
gpg-agent store in a special format. As soon as gpg-agent needs to use that key
and thus requires a passphrase anyway, the key will be re-encrypted on the fly.

We can change the interfactive import to continue processing with the next
keyblock if a passphrase was not given.

werner set Version to 2.1.
dkg added a comment.Apr 15 2016, 2:20 PM

I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.

my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.

So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.

marcus added a subscriber: marcus.

A decision must be made what the desired behaviour should be.

werner edited projects, added Feature Request; removed Bug Report.Jul 27 2017, 9:40 AM
werner added a project: S/MIME.

Well, iff we implement that for gpg we also need to implement it for gpgsm.