I think Werner addressed this on 2.1 with:

b03a2647299a6c8764a2574590cbaccdff9e497d

Attached is a backport of this patch to STABLE-BRANCH-2-0.

D307: 629_0001-gpg-Avoid-cluttering-stdout-with-trustdb-info-in-ver.patch

As DKG noted on the mailing list, we --batch shouldn't imply
--pinentry-mode=loop. He provides the example of a graphical tool that fills in
many of the fields when generating a key, but should not have to worry about
securely managing the password.

This suggests that if a password is somehow provided on the command line, we
should prime (i.e., preset) gpg agent so that it doesn't request a password.

This 1st step debugging modification on configure

• configure 2015/06/03 14:56:54 1.1
• configure 2015/06/03 14:57:45
• 14873,14878 ****
• 14873,14879 ---- else HAVE_INTTYPES_H=0 fi

+ HAVE_INTTYPES_H=0

      if test $ac_cv_header_sys_types_h = yes; then

permit a complete make && make check

opt.passphrase_repeat defaults to 1 (g10/gpg.c:2152).

I see two solutions:

• If we are in symmetric mode, then we set opt.passphrase_repeat to 0.
• We introduce a new mode in passphrase_to_dek_ext: create new key, but don't

prompt the user to confirm the password.

The former is acceptable if we never need to repeat the passphrase for
operations on symmetric keys, which I think is the case. I've attached a patch
that implements this behavior.

D301: 621_0001-Don-t-prompt-for-the-password-multiple-times-in-symm.patch

Some initial findings:

gpg2 calls gpg-agent as follows:

  GET_PASSPHRASE --data --repeat=1 -- S5E0584FFBBEA6E79 X X Enter+passphrase%0A"

So the problem is with gpg2.

Here's the backtrace in gpg2:

#0 agent_get_passphrase at ../../../gnupg/g10/call-agent.c:1376
#1 passphrase_get at ../../../gnupg/g10/passphrase.c:312
#2 passphrase_to_dek_ext at ../../../gnupg/g10/passphrase.c:537
#3 passphrase_to_dek at ../../../gnupg/g10/passphrase.c:594
#4 encrypt_simple at ../../../gnupg/g10/encrypt.c:217
#5 encrypt_symmetric at ../../../gnupg/g10/encrypt.c:53
#6 main 0x000000000040cbc5 in

passphrase_to_dek_ext calls passphrase_get and passes it the repeat
mode, which it reads from opt.passphrase_repeat.

A user id is not designed to be unique. Thus you can't rely on it. It, is
convenient to use a user id but it is only a shortcut.

To see why gpg selects a certain key we need to see more information - in
particular the output of "gpg -k".

BTW, your delete example is missing the quotes around the user id. And 2.0.14
is pretty old.

By killing I meant sending SIGTERM (15) through the kill command.

But
"gpgconf --kill dirmngr" also does not kill the dirmngr. Is this problem not
reproducible for you?

kill -9 kills it of course.

How do you kill dirmngr? Using "gpgconf --kill dirmngr" or by sending a signal

• which one?

Just to point this problem out again (still exists with current master of
course). The CRL checks during a normal start of kleopatra on my keyring leave
55 dirmngr zombies.

This problem is not really bad for me as I am using the attached Patch. Still
after 3 months I'd appreciate a reaction / review.

Here is a possible fix.
I write this for current master branch and tested.
Then, it is ported to 1.4. It builds and it seems working well.
Please test it out.
I was wrong in T1675 (gniibe on May 15 2015, 06:38 AM / Roundup) saying multiple races.
Provided write(2) is atomic, the race is only here for creating trustdb.gpg and
checking if it's there.

D206: 619_gpg14-create-trustdb-race-fix.diff

I removed the stub keys for the last two, that is why they are listed as "ssb#"
instead of "ssb>".

If the expected behavior is newest key is always preferred, than that's fine and
easy to work around with default-key, although it would be nice to exclude
unusable keys.

No, I don't think so. You created a newer subkey on a smartcard and thus gpg
assumes that you want to use that key.

It should actually ask you to insert that card - doesn't it do that? There is
an open bug which might prevent that gpg-agent asks for the correct card - is
that the case? The missing "Card serial no. = nnnn kkkkkkkk" may indicate that.

Did you ever used the cards with that version of gpg and did you run a "gpg
--card-status"?

The change is in gnupg 2.1.4.

it was a while back, and i removed an archive with my notes, so will need
to repeat when i have more time.
On May 11, 2015 8:22 PM, "Werner Koch via BTS" <gnupg@bugs.g10code.com>
wrote:

That might be possible. However outstarting gpg-agent won't be implemented for 1.4.

Regarding custom pinentry program, doesn't that mean to require a user to edit
gpg-agent.conf to enable/disable the custom pinentry program?

Yes, pinentry-emacs could implement the fallback mechanism to pinentry-gtk (i.e.
by checking if Emacs is running), but I think it is too much.

Perhaps gpg could have a --pinentry-program option too and pass the value to
gpg-agent?

BTW, I believe it would be better for Emacs to implement its own pinentry UI,
not using loopback mode.
I mean, something similar situation where we have emacsclient as an external editor.
If we have pinentry by Emacs, people will be able to invoke gpg on remote
machine and access local secret key by local gpg-agent which asks passphrase to
local Emacs's pinentry.

Currently, I don't know the solution. Here is some information, while I'd
understand your implied request.

With use-agent, the behavior is same between 1.4 and 2.1. 2.0 and 2.1 has
similar behavior (although it doesn't support loopback mode).
In 1.4, with cpr_enabled, it stops reading repeated input, which makes sense.

Fixed in b3fd30451a5464b124b0296afbc341cb98b3977c.

On Mon, May 18, 2015 at 10:37:08AM +0000, Werner Koch via BTS wrote:

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Exactly this thing I reported as a workaound. I'd like to see working gpg
without setting the GPG_AGENT_INFO variable before.

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Now, we have a patch to fix in the Debian bug tracker.

It was fixed in 2.1.4.

perhaps I missed something but...with the command removed how are we able to see
the private keys (esp the details on where they are stored (smartcards)).

There is some weirdness in the code. For example I can't remember why the order
for creating a log is different under riscos. Given that we have not tested
riscos support for ages it might be better to remove it entirely to remove a
source of error.

Creating the trusdb file should only be allowed while holding a lock on it.
That is one of the reasons we use a separate lock file.

The command should be removed because it does not make much sense anymore.
However, it is doumented at many places thus it is not easy to remove.

On 05/13/2015 11:13 PM, NIIBE Yutaka via BTS wrote:

I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

Yes, this is fixed. Sorry for forgetting to update this bug. Already noticed your
commits are signed - unfortunately, your commit signing key isn't signed by any other
of your keys, though.

Thank you for your time and cooperation.
Your data helps me a lot.
I think that same bug is in 2.0 and 2.1, too.
I'll try to make minimal reproducible scenario to locate the bug.

there is more info in 'gpg-info.txt' inside the tarballs, but for completeness
gpg --version: gpg (GnuPG) 1.4.18
lsb_release -sc: vivid
uname -a: Linux vivid-20150513-125547 3.19.0-16-generic #16-Ubuntu SMP Thu Apr
30 16:09:58 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
filesystem is ext4.

Attaching output of runs.
show-race-output-nostrace.tar.gz
and
show-race-output.tar.gz

both run on fresh 15.04 instance (gpg (GnuPG) 1.4.18).
nostrace version did not use strace. I had to run that in a loop in order to
catch failure. with strace, it fails immediately.

strace version (failed first time):

./show-race.sh

no-strace:
while :; do ../show-race-output/show-race.sh || break; rm -Rf out*; done

Please let us know your filesystem for .gnupg/ directory.
Unfortunately, I couldn't reproduce the bug with your script on my machine.
If possible, could we share the output of the script in your system?

This seems to work with gnupg-2.1.4. Thanks!

I forgot to update this issue, 2.1.3 already fixed it. Thanks!

This is about updating the docs. Will be done for 2.1 only.

This reminds me that we don't have a mail keyserver in 2.1 yet. Need to
evaluate whether it will be useful.

(funny due date removed)

Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.

Yes, auto-detection in dirmngr-client would be great, thanks!

Is this still a problem?