Hi Brian,

Does encrypt-to/hidden-encrypt-to in gpg.conf do this?

FWIW, I believe I saw this bug while debugging pinentry-curses. I committed
1d3583a2562e83496ac515276e9bd63a7f1abbc7 to pinentry to work around this.

This feature has landed in the latest 2.0 and 2.1 branches and support has been
added in pinentry. I'm closing this now.

Hi dkg,

On the mailing list and in T1928, we discussed
why it shouldn't be possible for a program to pass the passphrase to gpg agent.
This feature request is at odds with the conclusion drawn there. Should this
issue be closed as WONTFIX?

Thanks,

:) Neal

Hi, thomai,

Please run something like the following:

  echo | gpg2 --sign

Does gpg2 complain the the connection to gpg agent was hijacked? If so, please
disable GNOME Keyring and try to reproduce the problem.

If the problem continues to exist, can you tell me approximately how long your
password is?

Thanks,

Neal

Werner: Can you provide a bit more context? What exactly is full of bugs?

bjmgeek: ping

In another message (<874mnnlqxn.fsf@alice.fifthhorseman.net>) DKG notes that we
shouldn't allow loopback mode or preseeding to prevent passphrase-guessing attacks.

As DKG noted on the mailing list, we --batch shouldn't imply
--pinentry-mode=loop. He provides the example of a graphical tool that fills in
many of the fields when generating a key, but should not have to worry about
securely managing the password.

This suggests that if a password is somehow provided on the command line, we
should prime (i.e., preset) gpg agent so that it doesn't request a password.

I've now applied the patch.

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.

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)?

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.

opt.passphrase_repeat defaults to 1 (g10/gpg.c:2152).

I see two solutions:

• If we are in symmetric mode, then we set opt.passphrase_repeat to 0.
• We introduce a new mode in passphrase_to_dek_ext: create new key, but don't

prompt the user to confirm the password.

The former is acceptable if we never need to repeat the passphrase for
operations on symmetric keys, which I think is the case. I've attached a patch
that implements this behavior.

D301: 621_0001-Don-t-prompt-for-the-password-multiple-times-in-symm.patch

Some initial findings:

gpg2 calls gpg-agent as follows:

  GET_PASSPHRASE --data --repeat=1 -- S5E0584FFBBEA6E79 X X Enter+passphrase%0A"

So the problem is with gpg2.

Here's the backtrace in gpg2:

#0 agent_get_passphrase at ../../../gnupg/g10/call-agent.c:1376
#1 passphrase_get at ../../../gnupg/g10/passphrase.c:312
#2 passphrase_to_dek_ext at ../../../gnupg/g10/passphrase.c:537
#3 passphrase_to_dek at ../../../gnupg/g10/passphrase.c:594
#4 encrypt_simple at ../../../gnupg/g10/encrypt.c:217
#5 encrypt_symmetric at ../../../gnupg/g10/encrypt.c:53
#6 main 0x000000000040cbc5 in

passphrase_to_dek_ext calls passphrase_get and passes it the repeat
mode, which it reads from opt.passphrase_repeat.

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.

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.

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

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.

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.

Fixed in:

commit 189ab07e94dc2d4103c1edf00e15e0156df89297
Author: Neal H. Walfield <neal@gnu.org>
Date: Fri May 1 20:35:59 2015 +0200

When reading the pin, correctly handle backspace.

* tty/pinentry-tty.c (read_password): Handle backspace.

--

I think this needs to be a bit clearer:

In pinentry-tty.c:confirm, only the "ok" button's text is shown and it is
suffixed by a fixed string: "[y/N]", which should be internationalized.

This should be fixed in 5cde5bf. I tested building with LDAP and without. I
also ran some basic queries in the LDAP case and everything seemed ok. If I
don't hear about any further issues, I'll close this in the next few days.

LDAP has not been made a hard requirement; this is a bug.

Note: for more information about this issue, please refer to:

  T1945

  https://wiki.gnupg.org/GnomeKeyring

(I've added this here, since this page is one of the top hits on ddg and google
when searching for the warning message.)

This was a change in behavior in 2.1 (relative to 2.0 / 1.4) in which instead of
taking the last specified key server, all key servers were used. I've now
reverted this in f26ba14028d34845ae10aae552b90681907e377d.