With recent versions of OpenSSH, the default fingerprint shown is uses SHA256.
The fingerprints emitted in sshcontrol are MD5. You can get ssh-keygen -l to
produce comparable MD5 fingerprints with "-E md5".

Perhaps the generated sshcontrol should also include the base64-encoded SHA256
fingerprints as well, though?

That still doesn't explain why ecdsa 384 keys are mis-fingerprinted, though.

This is still a problem with 2.1.8

can you explain why the limit is useful? e.g. does it increase efficiency in
some metric? defend against certain classes of attack? something else? sorry
that i don't understand the tradeoff fully.

a runtime configuration would be better than a hard fail, but in either case it
seems like we're asking the user to fiddle with things that they shouldn't have
to think about or understand. is there a way that we can automatically detect
the reason for the failure and make things Just Work for normal users without
opening up the tooling to more problems?

with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:

0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$

maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:

0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc

3126   11384  481051

0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc

4310   13779  541937

0 dkg@alice:~$

hm, common/utf8conv.c says this:

  /* Note that we silently assume that plain ASCII is actually meant
     as Latin-1.  This makes sense because many Unix system don't have
     their locale set up properly and thus would get annoying error
     messages and we have to handle all the "bug" reports. Latin-1 has
     always been the character set used for 8 bit characters on Unix
     systems. */

I wonder if this is still the best choice. In my experience, far more machines
have text in some UTF-8 encoding today than in Latin-1. this is especially true
for systems that deal with OpenPGP User IDs, where UTF-8 is the canonical
representation.

If the user's environment claims that it's plain ASCII and we're seeing 8-bit
characters, gpg does have to make a decision about what to do. i see four options:

a) report an error and fail.

b) pretend that the 8-bit characters are Latin-1 (this is "OK" because any
bytestring is a valid Latin-1 string)

c) pretend that the 8-bit characters are UTF-8

d) do some sort of autodetection on the bytestring (e.g. if it is a valid UTF-8
byte sequence then treat as UTF-8, otherwise treat as Latin-1)

option (a) is annoying and likely a cause of spurious complaints, as the comment
notes. GnuPG is currently going with option (b). Option (c) seems more
reasonable to me because of OpenPGP's relationship with UTF-8, but introduces
some error cases (what do we do where the bytestring is not valid UTF-8?).
Option (d) avoids error cases but might be a bit more delicate to implement.

What do you think?

I think werner means --utf8-strings instead of --utf-strings.

D295: 667_0002-enforce-std-gnu-11-to-avoid-breakage-with-gcc5.patch

the attached patch is a minimal patch to make older versions of pinentry-qt4
build cleanly with newer gcc.

so far, the proposed mechanisms for getting at gpg-agent's memory from a peer
process running as the same user are:

a) ptrace (e.g. via /usr/bin/gcore or /usr/bin/strace)
b) /proc/$PID/mem, which is owned by the user and mode 0600

DarkStarSword's patch effectively closes (a) (by rejecting ptrace connections)
and appears on my GNU/Linux system to close (b) as well: /proc/$PID/mem is
root-owned when the patch is applied instead of being user-owned.

Are there other channels for per-process memory access that we should be
thinking about?

I agree with Werner and Neal that the UNIX model is probably insufficient to
close all the holes easily, but i also don't think that's a good reason to avoid
closing those holes we can close.

If there are other ways that another process by the same user can get at the
RAM, please point them out and i'll look into ways to address them too.

In the meantime, i'll also look into ways to facilitate running the process as a
separate user account entirely.

D128: 666_0003-Avoid-simple-memory-dumps-via-ptrace.patch

I'm going to introduce the prctl(SET_DUMPABLE, 0) change to main in
agent/gpg-agent.c in the debian 2.1.x series as of 2.1.7-1, using the patch i'm
attaching here.

I make no representations that this solves all possible memory leakages, but it
does address one specific and relatively straightforward attack.

As to Werner's legitimate concerns about making debugging harder, there remain
at least two options: ptrace as the superuser, and launching gpg-agent itself
under gdb directly.

If this experiment proves disastrous somehow (i'm not seeing how), we can always
revert the patch.

I agree with you that the standard UNIX model is generally insufficient here.

Perhaps the distros could weigh in with mechanisms to facilitate
secondary-account creation for agents and the like. I've opened
https://bugs.debian.org/794667 about this.

However, i don't think the weak UNIX permissions model is a reason to avoid a
small piece of code like that offered by DarkStarSword below. Closing off one
avenue of attack is still worthwhile, even if other avenues remain. As werner
said, gpg-agent won't create a coredump (even though other avenues of attack are
possible).

Is there something about the complexity of prctl(PR_SET_DUMPABLE, 0); that makes
it undesirable?

fwiw, i'd be fine with enabling protection against ptrace for gpg-agent, even if
that doesn't fix all the other ways a process can be attacked from another process.

if there are multiple holes, we should plug the ones we can plug, to increase
the pressure to make the other ones fixable.

If pinentry-emacs doesn't need to be distributed, why do we even have it as a
separate target (emacs/pinentry-emacs) that is enabled by default?

my concern about abuse of INSIDE_EMACS is as i said "vague" -- sorry, i hope
it's not FUD! here's a rough sketch:

pinentry is a sensitive program. its job is to protect sensitive data (secret
key material, passphrases) from unintended use. each hook that we put into
pinentry to allow an attacker to probe its contents, or to execute commands, or
to control the UI/UX of what is presented to the user, is another hook that can
be used to violate the protection we want gpg-agent to afford its users.

Consider an attacker who has access only to the gpg-agent socket, and to one
other socket on the system. If they can convince gpg-agent to talk to them on
that one other socket by setting INSIDE_EMACS during a communication to
gpg-agent, this seems like a risk. furthermore, it's an unnecessary risk for
users who have no intention of interacting with gpg-agent through emacs in this
way. (e.g. users of emacs under X11 sessions may prefer to use a graphical
agent, or users of emacs from a terminal may prefer pinentry-curses). it's not
clear if there's a way to tell gpg-agent at runtime to avoid this additional
communications vector either.

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

Looks to me like it just fails silently.

We can already do a dummy signature, but it feels sloppy for several reasons:

• it's not clear exactly what to sign with a dummy signature -- should you sign

static text or a dynamic (random) block?

• it's not clear what to do with the signatures after creation. It's

concievable that a dummy signature could be abused/misused if the material being
signed turns out to have some other meaning.

• gpg-agent can be configured to log to an append-only file as a means of

monitoring what signatures have ever been made by a given key. Dummy signatures
introduce spurious signing events that are indistinguishable from real
signatures in this log

• the creation of arbitrary signatures takes more time than testing passphrase

and returning feedback.

Hm, you make a good point about this being undesirable in the general case --
access to a normal gpg-agent shouldn't provide an attacker with a way to guess
passwords silently.

However, consider the mailpile case -- where gpg-agent is running on the
webserver, and the login webpage wants to verify a given user based on the
password for the user's secret key (and wants to avoid keeping some extra
/etc/shadow-equivalent file lying around).

Maybe such an application would start gpg-agent in a different/simpler mode? Or
should we recommend that such an application test the provided passphrase in
some other way, without using gpg-agent at all?

D306: 630_0001-gpg-Avoid-cluttering-stdout-with-trustdb-info-in-ver-STABLE-1-4.patch

And here is a backport to STABLE-BRANCH-1-4

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

ah, right! the other option is to pass mb->size instead of size in the memset call.

We should really synchronize secmem.c between libgcrypt:src/secmem.c,
pinentry:secmem/secmem.c, and gpg-STABLE-BRANCH-1-4:util/secmem.c :/

OK, something is definitely wrong with the secmem allocators.

I applied this patch:

diff --git a/secmem/secmem.c b/secmem/secmem.c
index 9a478cf..bf97a2a 100644

• a/secmem/secmem.c

+++ b/secmem/secmem.c
@@ -381,11 +381,16 @@ secmem_realloc( void *p, size_t newsize )

mb = (MEMBLOCK*)((char*)p - ((size_t) &((MEMBLOCK*)0)->u.aligned.c));
size = mb->size;

+ printf("A: %d\n", mb->size);

    if( newsize < size )
	return p; /* it is easier not to shrink the memory */

+ printf("B: %d\n", mb->size);

a = secmem_malloc( newsize );

+ printf("C: %d\n", mb->size);

memcpy(a, p, size);

+ printf("D: %d\n", mb->size);

memset((char*)a+size, 0, newsize-size);

+ printf("E: %d\n", mb->size);

secmem_free(p);
return a;

}

and ran pinentry-gtk-2 with "getpin" as an input and typed in 32 characters for
the dialog box. at character 16, it printed:

A: 32
B: 32
C: 32
D: 32
E: 32

and at character 32 it printed:

A: 0
B: 0
C: 0
D: 0
E: 0

I'm beginning to suspect that this allocator never worked quite right, and that
1d3583a2562e83496ac515276e9bd63a7f1abbc7 just exposes a flaw in the addressing.

Tracking this down further, it appears to be caused by
1d3583a2562e83496ac515276e9bd63a7f1abbc7.

If i revert that commit, the problem goes away.

This makes me think something is wrong with secmem_realloc or secmem_malloc.

thanks, neal. I see this committed as eab03a469d82018e53380f26390594f47bb4c5c8,
with a committer of "us <us@chu.huenfield.org>" -- since huenfield.org is
registered to you, i assume that's you? I'm used to seeing your commits as
coming from "Neal H. Walfield <neal@gnu.org>"

on the debian bug report, Felix Geyer notes:

This issue is still present.
Tested on current Debian unstable [0.9.2-1] with KDE4 and Ubuntu 15.04 with

KDE Plasma 5.

The patch from the Fedora package fixes the problem.

I note that this isn't yet applied upstream as of
55ea554b2020b1e7b0996bd9f7bb38c8af2b03f3 -- maybe this can be considered before
the next release?

(neal, i'm adding you to the "nosy list" here and assigning this ticket to you,
because of all your work on pinentry lately. I hope that's not overstepping any
boundaries! please let me know if you'd rather i didn't do that directly)

So what should we do about this? Do we need to keep gtksecentry.* in sync with
upstream's gtkentry somehow?

On a debian system, i did:

   apt install --no-install-recommends scim scim-gtk-immodule

Here is a transcript of pinentry being invoked: there is additional scim-related
output:

0 dkg@alice:~$ GTK_IM_MODULE=scim pinentry-gtk-2
OK Your orders please
GETPIN
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
GTK Panel of SCIM 1.4.15

Starting SCIM as daemon ...

at this point, no keyboard entry works in the module at all.

This is https://bugs.debian.org/750521

pinentry GTK-2 is still failing to accept any keyboard input when invoked with
GTK_IM_MODULE=scim

D303: 609_559936.patch

the reporter noted the same problem in 0.9.0, not just 0.7.6.

still, a re-test with 0.9.2 would be useful

sorry, that should be https://bugs.debian.org/581617 instead.

D302: 608_0001-Fix-qt4-pinentry-window-created-in-the-background.patch

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

The original reporter was on 2.1.0.

It looks like I can confirm this on 2.1.3.

This is still an issue with pinentry 0.9.1

I can confirm that this is resolved in 2.1.3 with .kbx files. Thanks for the fix!

I can confirm that this is resolved in 2.1.3:

0 dkg@alice:~$ gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

the error message isn't particularly helpful at directing the user to the source
of the problem (a bad dirmngr.conf), but at least it does return a non-zero
error code.

I would like to see this happen. It would be great if dirmngr could make
parcimonie obsolete, for example.

(should this be "category: dirmngr" instead of just adding it as a topic?)