I use several key of near all types: ed25519, rsa, dsa, ecdsa. All of them have
stopped working.

Duplicate of T2096

Are you using an Ed25519 key? There was a regression in 2.1.8 which has
meanwhile be fixed in the repo. See also T2096.

Solution (c) will be used for 2.1.8.

Won't fix in 1.4 because that version is mostly useful on old systems and those
don't have proper utf-8 supoort anyway.

Originally dirmngr was a system wide daemon. Thus a limit made a lot of sense
so that users could not oincrease the memory usage of dirmngr. As a user daemon
this is not too problematic anymore but (in contrast to GNU policy), having
limits is still good to avoid DoS. The packet parser also employs certain
limits, like 2K for a user ID or 16M for an attribute packet.

I assume keyservers also have some limit - or at least they should have one to
help against misuse as cheap storage provider. What about using this limit?

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?

To clarify werners comment. The revert is part of the 2.0 branch. I've
confoirmed the fix works so -> resolved) But awaiting a package / downstream
deployment.
The default for 2.0 won't be changed away from SHA-1.

This will be part of the next gpg4win release.

(Btw. Good to see you here sandro ;-) )

The limit set by dirmngr is in general useful. Shall we make the limit
configurable at runtime?

Oh well, the hang is indeed a libassuan bug. The assuan_inquire fucntion
stopped reading as soon as a supplied limit was reached and returned to the
caller. The caller (dirmngr), printed an error and sends back an ERR line.
Hwoever, the client kept on sending the remaining lines and thus messed uo the
protocol.

Just fixed it in libassuan (5a52404) by reading up the extra lines before
returing from assuan_inquire.

Re-assigning to gnupg. libassuan works correctly, afaics.
When trying to send back Zack's key I had the same problem last week and
increased the limit in dirmngr (84f4c8811fc5bdd78693c4dc289389a8337cc257).
I also mentioned that in a comment to another Debian bug report.

However, their should not be a hang but a proper error diagnostic; it is on my list.

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:~$

This is a regression in 2.0.28. The fix is
commit 35d3ced4fda90a5410a579850ca92ea6a356b402
which reverts to use SHA-1 for a CSR.

It works fine in 2.1 but backporting the changes is not planned.

i prefer solution (c): we should assume utf8, if we are going to assume anything
at all.

if the user doesn't provide UTF8 *and* doesn't have the proper locale set, then
we should exit with a meaningful message.

that way, things break for people that don't have a properly configured locale
*and* try to input non-UTF8 as opposed to just fail if locale is *not
configured*, which is a pretty common scenario.

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.

I did a couple of tests but I do not understand what is going on.
There is also an older key of Antoine 231A87628530E205 which encodes
his name in Latin-1 (wrong charset during creation or PGP was used).

Using

  gpg -vvv ....

shows the character set used by gpg. Maybe this gives some insights.
If you know that the command line is UTF-8 you may use the option
--utf-strings to avoid any conversion.

FWIW, gpg uses LC_ALL, LC_LANG, LANG in that order to determine the
locale. Antoine's original report shows

  Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)

and thus UTF-8 should be used due do LC_CTYPE. gpg converts command
line arguments back and forth as needed but passes them as utf-8 to
the keyserver (which is the reason that the "searching for =..."
message renders it differently.

Hi Brian,

I tried it in PuTTY without screen and it was not skewed. The line draw
characters looked funny (which I'm assuming is a Unicode thing), but they
were in a rectangle.

bjmgeek: ping

Done with commit 25331bb for 2.1.5.
Won't be backported to 2.0 or 1.4.

This also changes the publication date to the date of the last commit for one of
the texi files. This was the original intention of the version.texi file but
that did not worked in a git world.

Won't be done for 2.0 but I will try to implement that for 2.1

I've now applied the 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 :/

D305: 627_0001-secmem-When-clearing-memory-don-t-clear-beyond-the-e.patch

Well, that's embarrassing. It looks like it was my bug. The attached patch
seems to fix the problem.

I've been debugging this issue for about an hour and I tentatively came to the
same conclusion.

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.

OK, I'll try that too.

I will try this afternoon.

Also, see if you can reproduce the problem without screen. Thanks.

I tried your screen configuration and I couldn't reproduce the problem.

Perhaps putty is configuring something differently. Can you reproduce the
problem when putty is not used (e.g., directly on the console or ssh'ing from a
GNU/Linux box)?

On Tue, Jun 2, 2015, 11:19 PM Neal Walfield via BTS <gnupg@bugs.g10code.com>
wrote:

Here is my .screenrc

#change the hardstatus settings to give
an window list at the bottom of the
#screen, with the time and date and with
the current window highlighted
hardstatus alwayslastline
hardstatus string '%{= bK}%-Lw%{=
KW}%50>%n%f* %t%{= bK}%+Lw%< %{= kG}%-=%D
%d %M %Y %c:%s%{+b y} %H %l'

deflogin on
shell /usr/bin/bash
vbell on

Thanks for your quick reply. I meant: what program were you running on your
Debian box in screen? I doubt you directly called pinentry. Were you running
mutt? Were you running gpg?

Thanks.

I was using PuTTY 6.4 on Windows 7 64 bit.

I just tried running pinentry-curses under screen on debian in an
xfce4-terminal. (You can run it directly from the command line by running
pinentry-curses and then typing 'getpin'.) I wasn't able to reproduce what I
saw in your screenshot. Also, I saw the proper symbolic characters to paint the
widget's borders (see screenshot).

I've make some changes to pinentry-curses recently. Perhaps you can try that
version (git). If you get the same results, does hitting control-L correctly
repaint the screen?

What program were you running? Perhaps it messed with the terminal settings.

Fixed in b3fd30451a5464b124b0296afbc341cb98b3977c.

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

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.

I have fixed it for the gca functions percent and percent+ but won't do it in
the generic percent_exacpe C function. Changing the latter may introduce
regressions.

Fixed for 2.0 and 2.1.