chdiza: In the future, please open one issue per bug report. FWIW, I've also
fixed this new bug.

Given that this bug has existed since forever on Max OS X, I don't think this
issue is important enough to immediately do a release. However, there should be
a new release within the month.

Also, the OSX community would much appreciate it if you guys would cut a release
containing this fix as soon as possible. We aren't any less likely to misenter our own
passwords than anyone else :)

Neal: It works!

However you should be aware that I had to manually --disable-pinentry-emacs, or else
I got this:

-----8<-----------------------------
Making all in emacs
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/Cellar/gnoopeegee/1.8.0/include -
I/usr/local/Cellar/gnoopeegee/1.8.0/include -I../pinentry -Wall -g -O2 -Wall -
Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security
-W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -
Wno-pointer-sign -Wpointer-arith -MT pinentry-emacs.o -MD -MP -MF .deps/pinentry-
emacs.Tpo -c -o pinentry-emacs.o pinentry-emacs.c
mv -f .deps/pinentry-emacs.Tpo .deps/pinentry-emacs.Po
make[2]: * No rule to make target ../assuan/libassuan.a', needed by pinentry-
emacs'. Stop.
make[1]: * [all-recursive] Error 1
make: *** [all] Error 2
------------8<----------------------------

I myself don't use emacs, but probably there are some OSX users who'd want pinentry-
emacs.

Looks to me like it just fails silently.

chdiza: Thanks for your help! I'm sorry about the confusion. I overlooked your
previous message. I've change pinentry-curses to recognize 0xf7 (127) as
backspace (6ce1d0c curses: Recognize ASCII DEL as backspace.) If this change
didn't fix the issue, please reopen.

Thanks for this report: you are absolutely right, we need to check if the actual
secret service is usable and not only if the library is available.

How exactly does pinentry fail? Does it just silently fail to save the
password? Does it still return the entered password to gpg-agent?

Thanks.

Can you still try building with the supplied patch and sending me the scancodes

for delete.

Sorry, I don't understand. I did build with the supplied patch, as I reported below,
and I included the output of /tmp/pinentry-curses-output.txt as instructed.

If get back as far as 0.9.1 and the bug is still present, then it wasn't
introduced by recent changes. That's good to know.

Can you still try building with the supplied patch and sending me the scancodes
for delete.

Thanks.

I attempted to bisect, but when I when back to version 0.8.1, I could not build. I get
stuff I don't understand and don't know how to fix, like:

config.status: error: cannot find input file: `gtk/Makefile.in'

And other stuff that seems related to older checkouts needing different versions of
autoconf/automake. I simply don't have the expertise to deal with that, or the time to
curate multiple versions of autotools. So I can't git bisect.

I did however find that the oldest release version of pinentry that I could build on my
system was 0.7.1, and it also had broken backspace/delete/whatever.

I also tried on OSX 10.5.8, same thing.

I suspect pinentry was always broken on OSX.

It sounds like you are missing some build dependencies. Perhaps something

related to iconv?

Well, I don't know. I'm not a programmer. I am not missing any deps when I build the
released versions of pinentry. I don't know what's different about the git repo
versions.

I made sure gettext was in my path and tried again, having applied your patch. It
compiled.

I then followed your original instructions. I typed:

onetwo<the-key-called-Delete-on-Mac>

and hit OK.

The contents of pinentry-curses-output.txt was:
6f
6e
65
74
77
6f
7f

Needless to say, "backspacing" still failed.

It sounds like you are missing some build dependencies. Perhaps something
related to iconv?

Looking at the keyboard, that appears to be the backspace key. (The last Mac I
used was an Apple 2E in school.) The backspace key works fine for me and I
don't have access to a Mac to debug the issue, so I'm going to need help. It
would be great if you could get pinentry to compile and used git bisect to find
the change that caused the problem (I'm assuming that the bug didn't exist at
some point).

Thanks.

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I mean the key which has the word "delete" on it, as seen in the gallery here:
https://www.apple.com/keyboard/. It is in the same spot, and is labeled "delete",
on all Mac keyboards, not just the model shown in that gallery. They key in
question is the one that Mac users press to simultaneously back up the cursor and
delete whatever char was in the arrive-at position.

Probably now someone will tell me that the key is improperly labeled by Apple :)

The delete key never did anything, because the cursor is always at the end of

the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

I had to clone the git repo first. Once there, I applied the patch and I ran
autogen.sh. I can't get the resulting configure script to work. Both "./configure"
and "./configure --enable-maintainer-mode" result in the following:

---8<-----------------------------------
checking for ncursesw... no
checking for ncurses... no
checking for initscr in -lncursesw... no
checking for initscr in -lncurses... yes
checking for ncurses include dir... none
./configure: line 8466: syntax error near unexpected token `iconv'
./configure: line 8466: ` AC_LIB_LINKFLAGS_BODY(iconv)'
---8<-----------------------------------

D313: 647_0001-Add-debuging-output.patch

The delete key never did anything, because the cursor is always at the end of
the line. (Delete deletes the character in front of the cursor.) Perhaps you
mean the backspace key.

Please apply the following patch. The run: build-dir/curses/pinentry-curses and
type getpin. You'll be prompted for a pin. Type in some text and then press
"delete". Then please reply to this issue with the exact text that you typed
and the file /tmp/pinentry-curses-output.txt

Thanks.

Just checked:

  /* Reset the pinentry (in case of popup messages). */
  agent_reset_query (ctrl);

Thus the pinentry is only closed if it is used as a simple popup winode (e.g.
"Insert card with serial number xxx") but not for a regular Pinentry.

Actually there should be no need for gpg to notigy gpg-agent and thus pinentry
about a Ctrl-C. Due to Ctrl-C the gpg process dies and thus the connection to
gpg-agent receives an EOF/SIGPIPE and gpg-agent will shuot it down. Thus the
connection cleanup handler of gpg-agent needs to kill an open pinentry - I
tought this is already done.

Or is it the case that gpg does not see the Ctrl-C?

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

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.

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.