"gpg --import" should only need the gpg-agent if a secret key is being imported,
but it appears to auto-launch the agent even if it's just importing a public key.
This results in unnecessary gpg-agent processes on systems that don't expect to
ever deal with secret key material.
sure: using the attached "dkg.gpg" file (a pruned version of my own public key),
i did:
0 test@alice:~$ export GNUPGHOME=$(mktemp -d) 0 test@alice:~$ gpg --import < /tmp/dkg.gpg gpg: keybox '/tmp/tmp.X15I5PraCp/pubring.kbx' created gpg: /tmp/tmp.X15I5PraCp/trustdb.gpg: trustdb created gpg: key CCD2ED94D21739E9: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported gpg: Total number processed: 1 gpg: imported: 1 0 test@alice:~$ ls -la $GNUPGHOME total 12 drwx------ 3 test test 140 Sep 5 20:51 . drwxrwxrwt 24 root root 880 Sep 5 20:51 .. drwx------ 2 test test 40 Sep 5 20:51 private-keys-v1.d -rw-r--r-- 1 test test 1296 Sep 5 20:51 pubring.kbx -rw------- 1 test test 32 Sep 5 20:51 pubring.kbx~ srwx------ 1 test test 0 Sep 5 20:51 S.gpg-agent -rw------- 1 test test 1200 Sep 5 20:51 trustdb.gpg 0 test@alice:~$
Note that S.gpg-agent wouldn't have been there if the agent wasn't running, and
indeed it disappears if i do the following while $GNUGHOME is still set:
gpgconf --kill gpg-agent
A subsequent re-import of the same file does *not* re-launch the agent, but a
subsequent import of a different file (generated by "gpg --export-options
export-minimal --armor --output wk.gpg --export
80615870F5BAD690333686D0F2AD85AC1E42B367") *does* re-launch the agent.
Thanks. It happens only for a new or modified key. The reason is that we then
check that the preferences of the key match our implementation. This check
makes only sense if we have the secret key and to detect this we need to start
the agent.
To avoid this, we would need to implement yet another gpg option.
Or we use a hack to detect the presence of the private-keys-v1.d directory.
That would solve the problem for now but not if the agent is accessed via the
--extra-socket feature.
So i see a couple options:
a) We import a secret key -- this requires that we launch the agent to store it.
b) We import a public key and see that its preferences do match our
implementation -- in this case, we don't need to talk to the agent, right?
c) We import a public key and see that its preferences do not match our
implementation -- in this case, we could check whether the agent has the
corresponding secret key, and if it does, we could complain to the user.
instead of (c), though, we could trigger such a test the other way around: if
we're using a secret key and we notice that its public preferences don't match
our implementation, that's when we could warn the user about the mismatch.
If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:
Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.
I think we should apply the proposed patch.
Then we can focus on case (c) and whether we think that import generally is the right place for such a prompt (maybe the answer is that we want it at import *and* at use?)
The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.
I'd like to close this was wontfix.