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.

I cannot reproduce this problem anymore. Neither with the test case
script, nor during ssh authentication with several card-reinsertions.

Is this still an an issue (2.0.4 is pretty old)?

Moritz, this should be fixed in the current SVN of 2.0.10. Would you mind to
test it?

Just as a quick follow-up to this script I wrote:

Moritz Schulte created a test case for this or a similar problem:

(Assigning to Werner, because the Problem is still there.)

The problem is still there with
Kontact proko2 2.1.12 and gnupg-agent 2.0.9-0kk2 on Debian Sarge.
And Kontact enterprise35 20080826.852422 Etch.

the username/philkime thing was just a typo, should both be "username". I can't
remember what the problem was any more, just that using "eval gpg-agent ...
didn't work properly and the agent couldn't be contacted when using
--use-standard-socket. I worked round it by just ignoring the STDOUT output of
gpg-agent when started and assuming that the socket is at ~/.gnupg/S.gpg-agent.
I think this issue can be closed.

Did you su to root and thus kept $HOMe at the old value? I do not understand
why you have "username" in the ls but "philkime" in the $HOME (which gpg-agent
uses to construct the name of the socket).

Upgrading from 2.0.7.svn4643-0kk1 and from 2.0.7-1kk2 to 2.0.8-0kk1 worked fine.
(tested on two machines, both having a running gpg-agent and then decrypting
OpenPGP and S/MIME messages)

You are using an old gpg-agent which does not support this option.
Below is the patch to allow using an old gpg-agent (I will commit it later).

Hmm - which part couldn't you replicate? I think you're right about the ssh
functionality - I think that's perhaps what I hit. But isn't it confusing to
have gpg-agent report a socket number it doesn't use when started with
--use-standard-socket? Or maybe that's what you couldn't replicate? Here is a
typescript of what I see:

I fixed it in agent/* and common/*. However, I don't think that this fix is
needed. It later turned out that we are already running gpg-agent with gettext
clamped to utf-8 to that the fix does nothing.

Werner,
thanks for the fix.
Just quickly?
In which component did you fix it? Is there an easy way to get a patch?

Works for me. However I was not able to replicate the original case because I
have no 2.0.5 available.

I found and fixed the problem. Now testing...

$ locale
LANG=de_DE@euro
LANGUAGE=de_DE:de:en_GB:en
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=