I was using PuTTY 6.4 on Windows 7 64 bit.

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.

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)

A user id is not designed to be unique. Thus you can't rely on it. It, is
convenient to use a user id but it is only a shortcut.

To see why gpg selects a certain key we need to see more information - in
particular the output of "gpg -k".

BTW, your delete example is missing the quotes around the user id. And 2.0.14
is pretty old.

By killing I meant sending SIGTERM (15) through the kill command.

But
"gpgconf --kill dirmngr" also does not kill the dirmngr. Is this problem not
reproducible for you?

kill -9 kills it of course.

How do you kill dirmngr? Using "gpgconf --kill dirmngr" or by sending a signal

• which one?

Just to point this problem out again (still exists with current master of
course). The CRL checks during a normal start of kleopatra on my keyring leave
55 dirmngr zombies.

This problem is not really bad for me as I am using the attached Patch. Still
after 3 months I'd appreciate a reaction / review.

Can you let me know when you can take a look at this or was my assignment wrong
here? (If so please change it)

This is a pretty major bug imho that would leave our application servers
(without manual intervention) if we would deploy 2.1 in our company. As such it
is blocking our adoption of 2.1.

I would appreciate some kind of reaction / confirmation on this issue.

Here is a possible fix.
I write this for current master branch and tested.
Then, it is ported to 1.4. It builds and it seems working well.
Please test it out.
I was wrong in T1675 (gniibe on May 15 2015, 06:38 AM / Roundup) saying multiple races.
Provided write(2) is atomic, the race is only here for creating trustdb.gpg and
checking if it's there.

D206: 619_gpg14-create-trustdb-race-fix.diff

I removed the stub keys for the last two, that is why they are listed as "ssb#"
instead of "ssb>".

If the expected behavior is newest key is always preferred, than that's fine and
easy to work around with default-key, although it would be nice to exclude
unusable keys.

No, I don't think so. You created a newer subkey on a smartcard and thus gpg
assumes that you want to use that key.

It should actually ask you to insert that card - doesn't it do that? There is
an open bug which might prevent that gpg-agent asks for the correct card - is
that the case? The missing "Card serial no. = nnnn kkkkkkkk" may indicate that.

Did you ever used the cards with that version of gpg and did you run a "gpg
--card-status"?

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.

Well, here's my fix. Using this neat little program I downloaded called
Resource Hacker, I edited the buttons on the dialog box so that they would
be big enough to display the messages needed. Realizing that pinentry.exe
and pinentry-w32.exe were identical files (checking them in a hex editor
with file comparison function showed them to be exactly the same), I just
copied my edited version of pinentry.exe and renamed the copy as
pinentry-w32.exe. I have put both of them in a zip file called
pinentry.zip, and have attached this zip file to this email. Feel free to
distribute this on the official GPG4Win website. Note that the file name of
the attachment is "piz" not "zip", so before you extract its contents (for
use, or posting on your website) you will need to rename it from "piz" back
to "zip". I had to rename it from "zip" to "piz" because otherwise Gmail's
mail server scans inside the zip file and then for blocks it because it
detects exe files (and exe files are a format that can potentially harbor
malware). Even though this has no malware (as you can see by scanning it
with a virus scanner), Google's mail server takes extra precautions by
refusing to allow sending of executable files or even archive files that
contain executable files.

As far as I know, GPG4Win is a compiling/linking of GPG to be Windows
compatible, which means that the code was already altered to work with
Windows. Therefore native Windows code is already in use in the GPG4Win
variant of GPG. Therefore it should work correctly in every respect in
Windows (including correctly sized buttons).

It was already on my own todo list (i.e. ticked in the mail folder). Thanks for
adding it to the tracker.

The change is in gnupg 2.1.4.

This requires native Windows code to resize a button in a dialog. This is to
much work for something which is basically a debug tool. I have called several
years for help on building a good native Windows tool (without MFC and such) to
no avail.

Feel free to send a working patch to gnupg-devel@

Even so, this is a bug. As such, it should be fixed.

it was a while back, and i removed an archive with my notes, so will need
to repeat when i have more time.
On May 11, 2015 8:22 PM, "Werner Koch via BTS" <gnupg@bugs.g10code.com>
wrote:

That might be possible. However outstarting gpg-agent won't be implemented for 1.4.

You are using the very simple native WIndows Pinentry. This is more a debug
tool than a real solution. I guess you installed the vanilla version of gpg4win
which comes without any GUI dialog except for this Pinentry. Please install at
least the light version of the installer.

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

Regarding custom pinentry program, doesn't that mean to require a user to edit
gpg-agent.conf to enable/disable the custom pinentry program?

Yes, pinentry-emacs could implement the fallback mechanism to pinentry-gtk (i.e.
by checking if Emacs is running), but I think it is too much.

Perhaps gpg could have a --pinentry-program option too and pass the value to
gpg-agent?

BTW, I believe it would be better for Emacs to implement its own pinentry UI,
not using loopback mode.
I mean, something similar situation where we have emacsclient as an external editor.
If we have pinentry by Emacs, people will be able to invoke gpg on remote
machine and access local secret key by local gpg-agent which asks passphrase to
local Emacs's pinentry.

Currently, I don't know the solution. Here is some information, while I'd
understand your implied request.

With use-agent, the behavior is same between 1.4 and 2.1. 2.0 and 2.1 has
similar behavior (although it doesn't support loopback mode).
In 1.4, with cpr_enabled, it stops reading repeated input, which makes sense.

Fixed in b3fd30451a5464b124b0296afbc341cb98b3977c.

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.

On Mon, May 18, 2015 at 10:37:08AM +0000, Werner Koch via BTS wrote:

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Exactly this thing I reported as a workaound. I'd like to see working gpg
without setting the GPG_AGENT_INFO variable before.

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

That is a very old gnupg version - You better update GnuPG to 2.0.27 and
Libgcrypt to 1.6.3.

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.

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

It was fixed in 2.1.4.

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.