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.

dkg: Thanks for pointing that out. I need to fix my git config on this machine.

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.

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>"

After chatting with Werner, we decided to apply the patch. If Andre has any
objections, he is still welcome to voice them.

I don't know much about Qt / KDE so I have a difficult time evaluating this
patch. However, given that this problem has persisted for a long time (since
2010); that Fedora has been distributing this patch; and that Felix still sees
this problem without the patch, but doesn't see it with the patch, I'm inclined
to apply it.

I've added Andre to the nosy list. He has much more experience with Qt and KDE
than I do. If he also thinks it is reasonable to apply the patch, then I'll
apply it.

P.S. Feel free to add me to any bug that you think I could help on.

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)

We implemented support for the GTK_IM_MODULE ebvar before 2007 thus I think this
is more likely a regression. In fact I recall that Marcus once showed me a
problem with his SCIM installation while using Pinentry.

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

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

I also added support for control-h (backspace) and control-l.

Thanks!
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blobdiff;f=pinentry/pinentry-curses.c;h=183fdb4f3ddef8535a8890178a610ac56a8880ae;hp=e7220094fce3375ddfefbe7353a36c998d406ef5;hb=d3c52a144b5b23d0d841a99a310090dcafe2074b;hpb=1d3583a2562e83496ac515276e9bd63a7f1abbc7

I don't have a definite authoritative list of escape codes, but those seem to be
the most common ones with use cases in pinentry.

It uses GTK features not availabale on my version. With some replacement macros
you should be abale to aplly it anyway.

D271: 610_0001-Using-a-simple-GtkEntry-instead-of-our-custom-implem.patch

If I disable the secure entry widget (see patch) and start pinentry as follows:

  GTK_IM_MODULE=scim gtk+-2/pinentry-gtk-2

then I'm able to enter text in the same way as with gedit.

This means that the problem is not due to grabing the keyboard, but most likely
due to our secure entry widget. Note: the secure entry widget is based on a
2004 copy of GtkEntry so it's not surprising that it doesn't support some modern
features.

I tested your pkg-config patch on Debian Jessie and everything still compiles
fine. I've applied the pkg-config patch. If gentoo is now using a newer
version of this patch, please let me know. Thanks.

I'm having trouble reproducing this issue. When I su, root doesn't suddenly own
the terminal:

  $ su -
  Password: 
  # ls -l $(tty)
  crw------- 1 neal tty 136, 4 May 16 22:52 /dev/pts/4
  #

Can you provide a minimal example that illustrates the problem? Thanks. I
realize this issue is very old.

Fixed in edd9a88.

I added support for control-u, control-w and alt-backspace in d3c52a1. Do you
think there are any other useful escape codes?

This might also be due to our custom secure entry widget. See this bug report:

T1239

Thanks for the great minimal working example.

I tried to reproduce this and I could.

However, when I run

  GTK_IM_MODULE=scim gedit

I can't enter any text either. I have to activate scim by pressing it's hotkey
(control-space). Then I can type as usual. pinentry grabs the keyboard to
prevent other applications from snooping the password. I guess this is
inhibiting scim/scim bridge from accessing the keyboard input.

This works for me with Werner's patch. Closing.

Fixed in 88772dd.

I've revamped pinentry-tty. Instead of displaying y/n, it now uses the first
accelerator or, if there are none, the first alpha numeric character for each
button.

Ctrl+W might not be as useful as Ctrl+U, but I think on Unix that's standard
behavior that can be expected. cryptsetup of LUKS knows it, too.

I wonder how useful this is. When entering your password, you can't see it.
Thus, if you make a mistake are you really able to recover by deleting the last
word? I don't think I could. If werner still thinks it is a good idea, I'll
implement it, but I think it is a waste of time.

The patch seems reasonable. Applied.

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.

Unfortunately, yes. Still happening with 0.9.2.

From looking at the error (I don't have gcc 5 at hand) this looks to me like a
problem in the stdc++ library.

It appears that the basic_string implementation wants to put the templates class
(QChar) into a Union and it fails because it has a non-trivial constructor and
this is not allowed.

As this currently works, either the stdc++ library does this differently or gcc
does not check that rule.

Depending on the GCC Version during build configuration I guess we could add
-std=gnu++11 as the error message suggests if the GCC mayor version is > 5

Afaik this is not a pinentry-qt issue as the style looks ok under Unity (ubuntu)
and Windows.

I want to investigate why that is the case and figure out what the problem is
exactly (other KDE password entries in the same style environment look slightly
better) so I left this open to remind me.

I've clarified the title.

fixed by using

1. pragma GCC diagnostic push
2. pragma GCC diagnostic ignored "-Wstrict-prototypes"

...

Andre: Can we fix that without the need to require a newer gcc version?

Okay. The secentry needs some work anyway to allow for a hide/show button. This
will probably go in the 0.9.3 release because it is too late for 0.9.2

We had 7 more releases after 0.7.6 Can you please test with 0.9.2 which will
be released today.

Does this still happen with 0.9.1 or 0.9.2 which will be released later the day.

Fixed with 0.9.1 which has a new option parser.