Glad I was able to help get one bug fixed at least :)

The in-memory encryption will definitely help in this scenario (that is, a
casual attack by e.g. a colleague or another student having a laugh as their
friend left their screen unlocked... real attack - I should know, I've done it,
and had it done to me, as had several of my friends back in uni (to be fair -
that was on Firefox password manager, but it could just as easily have been
gpg-agent)... This is not about stopping a motivated attacker with physical
access to the system as they could always subvert the system in other ways e.g.
adding a shell alias to run a trojaned gpg-agent instead of the real thing,
install a key logger, etc).

I'm still not super happy that a casual attacker could walk away with a core
file containing the encrypted passphrase and the key to decrypt it. What started
as a casual attack for a laugh could later transform into a more serious attack
given that they can hold onto this information indefinitely. I'm not a motivated
attacker, but that would tempt the hell out of me if I was even slightly so
inclined. I should know, because I've been in a similar situation in the past
where I obtained an unshadowed passwd file (through a purely casual attack when
I was looking up a friend's uid and discovered the passwd file was not
shadowed... so of course I made a copy). I could have left it alone, but it
tempted the hell out of me and I ended up running john over it for two straight
weeks (never did much with the result, but that's not the point)!

I would hope that the developers of any security product learns to think like an
attacker.

I must say I am deeply troubled by the priority seeming to be on the ease of
debugging a security product which has the sole purpose of keeping a passphrase
safe. As the saying goes security is always a trade-off, but given that
gpg-agent is a security product and not a word processor, this particular trade
off does not sit right with me. I would expect the development team to have root
access on their own systems, which avoids the issue as the root user can always
attach a debugger with or without this change - is there truly a reason that
they need to attach to a running gpg-agent on a system they don't have root on?
And what about the thousands of gpg-agents running on other systems in the wild
that should never need to attach a debugger (and if they do... sudo)?

The information about FIPS mode and SELinux is good to know, at least for people
running distributions that support and enable them by default. But from what I
can gather FIPS mode is a RHEL only feature (I may be wrong - I'm not all that
familiar with it), and SELinux is still either not enabled, or in permissive
mode in many distributions by default (including Debian and Ubuntu).

As I mentioned in the original report, an alternative way to protect the memory
of gpg-agent is to install it with the setgid bit set (ssh-agent does both the
prctl() and setgid for example - now there's some developers I applaud). Unlike
SELinux and FIPS mode this works in every distribution and has been supported
for donkeys years.

Without this I can do gcore pidof gpg-agent and QUITE CLEARLY see my
passphrase in the produced dump:

ian@draal~ [i]> gcore (pidof gpg-agent)
0x00007fb8f8849293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1560/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffce0a12000.
Saved corefile core.1560
0x00007f2dd583c293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1540/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffccfbe3000.
Saved corefile core.1540
ian@draal~ [i]> strings core.1560 | grep pass
passwd
This is my ultra secure passphrase - I definitely expect any program that

manages this to take reasonable steps to keep it safe even if I accidentally
leave my screen unlocked one day!

Invalid passphrase; please try again
You need a passphrase to unlock the secret key for user:%0A"test123

<test@test.com>"%0A2048-bit RSA key, ID DE3A7EAB, created 2015-08-06 (main key
ID F459B571)%0A

    SETERROR Invalid passphrase; please try again
    his is my ultra secure passphrase - IQ
    ian@draal~ [i]>

With this one line change I cannot do the above - that's the definition of
reducing the attack surface last time I checked.

You absolutely can still use gdb to debug it - you just have to start it under
gdb as opposed to attaching to an existing process, or attach the debugger as
root. You could also just disable the syscall in a debug build.

So a single syscall to demonstrably reduce the attack surface really complicates
things does it?

News to me.

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.