As I already explained: It works for me using the qt pinentry!

The release pinentry 0.8.0 version (from 2010-03-03) is based on svn222 (see
tags(pinentry-0.8.0).

Use the released 0.8.0 qt pinentry and not some earlier (i.e. -svnXXX versions).

Just to make sure:
I tested with gnupg 2.0.16 + pinentry 0.8.0-svn234.
You say that I should test gnupg 2.0.16 + pinentry 0.8.0-svn237.
Right?
(But in T1237 (wk on Sep 28 2010, 01:05 PM / Roundup) you wrote: "you need a newer gnupg".)

2.0.16 should be sufficient, though. Just use a recent pinentry-qt.

Right, you need a newer gnupg. Pinentry has no i18n support, thus your tests
are pointless.

Fix confirmed. Tested with gpg4win 2.1.0-svn1569.
So resolved.

This is not a bug but expected behaviour: We want to show the pinentry on the
correct xserver or tty and thus gpg-needs to know which one it is. The manual
has even a hint how to show the pinentry on the client machine:

Yep, there is a bug in gpg-agent. Fixed for 2.0 in svn rev 5423. Patch for
gpg4win commited.

Test works also for gpg4win 2.1.0-beta1 if created an empty file gpg-agent.conf
before gpg-agent is started:

There seems to be a relation if gpg-agent.conf exists or not.

I checked again: I can see no changes in my working copy since 2.0.16.

Just to note:
I tested with the debian package pinentry-qt (0.8.0.svn234-0kk1) from
files.kolab.org. It's the same problem with pinentry-qt and pinentry-gtk (see
test below).
You wrote that pinentry-qt works corectly since 0.8.0 (=svn222). I can't confirm
this with my test below. Or do you mean, that the additional changes in gnupg
are required for show the german "Abbrechen" button text in pinentry-qt?

My retest with gnupg 2.0.16...

Please run my tests.

Sorry, the "set GPG_AGENT_INFO..." line was pasted from my windows test. My
GNU/Linux test starts of course with:

What do you think

There are actually two problems here.

$ gpg-agent --version
gpg-agent (GnuPG) 2.0.16

Note that pinentry does not have any i18n features. The labels for all buttons
as weel as the prompts are provided by the caller. The Cancel you see are
merely fallbacks.

This is not a pinentry problem but one of gpg-agent. What version of gpg-agent
are you using?

Today I just had the problem again (/dev/pts/9, still same verisons as in T1203 (thomas on Jul 29 2010, 03:35 PM / Roundup))

Just had the problem on /dev/pts/9 while no problems since 2010-07-29 (because I
usually start mutt in a certain screen window where I made sure that it has a
high-enough tty number)

D134: 305_used-scdaemon-doc.patch

Still a problem with gnupg-agent 2.0.14-0kk2 and pinentry (or pinentry-qt in
curses mode because of unset $DISPLAY) 0.7.6-0kk1 on Debian lenny:
Does not work on /dev/pts/7, works on /dev/pts/72

Your logs show /dev/pts/7 and as I wrote in T1203:
other bug reports indicate that any /dev/pts/(single-digit) exposes the problem.

Fixed. Thanks.

gpg-agent won't create a core dump; see disable_core_dump(). However it is
still possible to read the memory of a process you own using ptrace or
/proc/PID/mem.

I recognise that gpg-agent is a user process - if it wasn't this issue wouldn't
apply at all.
And naturally this won't protect the user from themselves entirely - why if they
wanted, they could even start gpg-agent from gdb and skip the prctl call and
after entering his passphrase could then dump it from gdb. Or maybe they could
use an alternate "gpg-agent" that does not disable ptrace. Or they could wrap
gpg-agent and disable the call with LD_PRELOAD. Hell, if they wanted they could
probably even post their private keys unencrypted on a public webserver.

You can't protect a user from himself. gpg-agent is a user process and not a
system wide daemon.

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20100317 16:00]:

Werner Koch <wk@gnupg.org> added the comment:

What pinentry version are you using (qt or another one)?

What pinentry version are you using (qt or another one)?
Did you set the GPG_TTY envvar?

D126: 284_clear_passphrase.patch

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.

This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.

Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?

According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.

Is there any more information I can provide? Can you reproduce it?

This is the built-in reader in my Dell Latitude D430, by the way.

This is the relevant lsusb output:

What card reader are you using?

Okay, fixed in SVN 4958.

Tested with gpgsm 2.0.10-svn4835 and pinentry-curses 0.7.4. Works fine now. I
did have to explicitly set GPG_TTY, though, to make pinentry-curses work, but
that's unrelated to this issue.

No response, assuming it has been fixed.

Done in 4888. For scdaemon this is a half second and for gpg-agent every third
second.