I'm not using pinetry, it is part of the pgp software. just trying to
get to the bottom of this. I am a user, not a programmer. Pinetry just
makes the popup that's asking for the password. I attached a screenshot
of it.

This is Linux From Scratch, pinentry 0.9.7, pinentry -> pinentry-gtk-2, with
fallback to ncurses. No other pinentry program works.

This is KDE environment, Qt pinentry crashes. I can confirm that there's a
keyring password in the Login keyring, which is the only keyring I use.

Nonetheless, the password won't be asked again while the gpg-agent is running,
the password was entered at least once, and the "Remember password (or
whatever)" box was checked.

As soon as gpg-agent is terminated or a session restarted (which also terminates
gpg-agent), next time I try to use the pgp key, I get asked for its passphrase.

What distribution are you using? What pinentry program? Can you take a look
using seahorse to make sure that your password is saved. Once it is saved, it
shouldn't be removed.

Note: recent versions of pinentry-gtk-2 are using native widgets. If you are
using that program and not the latest version of pinentry, then please try that
first.

There is no version 2.0.22 of pinentry (the most recent version is 0.9.7). Can
you please figure out what version of pinentry you are using and which pinentry
program (there are five: pinentry-gnome3, pinentry-gtk-2, pinentry-qt,
pinentry-curses and pinentry-tty). Thanks!

I think I wasn't clear. I have two monitors, but only one X DISPLAY. This is
about the screen, not the X display, where the pinentry is shown.

You may use gpg-agent's --keep-display to force the pinentry to show up on the
display you started the agent. The agent needs to be started explicit, though.

A library should never ever send any diagnostics to stdout. That does not only
break pinentry but also all other tools which output to stdout. I suggest to
report that to libsecret.

Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:

0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $

Yes, pasting into pinentry-gtk-2 with the middle mouse button does work.

I noticed that pinentry-gnome3 uses GcrSystemPrompt, which is documented as
being a system modal prompt. I'm not very familiar with libgcr, but maybe
pinentry-gnome3 could use GcrPromptDialog if no-grab is set.

The gnome3 problem is due to libgcr, which disables and manages the dialog.

I'll take a look at the gtk2 issue soon. Does pasting with the middle mouse
button work?

Actually there is something more.

While using pinentry-gtk-2 in a terminal does work, it still fails in
Thunderbird/Enigmail (passphrase not recognized).

And pinentry-gnome3, that works in the terminal too, doesn’t work in
Thunderbird/Enigmail as stated before (it fails just like if set to pinentry-tty
or pinentry-curses).

So, found it why trying what you asked me for.

It has to do with Input Method. GTK3 is working because it’s the only toolkit
that properly recognize all the dead keys on my setup (some of the characters I
use are only available through dead keys). QT4 was working because of this line
in my .xprofile:

export QT4_IM_MODULE=xim

Replacing QT4 with GTK makes pinentry-gtk-2 work too. However, this seems not
supported by QT5 (the correct var is QT_IM_MODULE), because xim seems to be
obsolete so they don’t support it. But some of my dead keys are not working, so
this is most likely a bug on QT/KDE side…

And since I run a QT5 terminal, -curses and -tty don’t work.

So, I think this can be closed, and that it’s time to open/search a bug
regarding this on QT/KDE side.

if there is a behavioral change regarding the encoding a difference between qt4
and qt5 this would be a bug. Both convert the input to UTF-8, I think GTK does
too. I've just tested it and it worked.

So they should be the same. Can you provide an example test case by starting
pinentry from the command line and using "getpin"?

There is no encoding at all for passphrase - GnUPG uses whatever the user types.
Thus if the passphrase was originally entered on a Latin-1 TTY and later a GUI
with UTF-8 input is used, you run into problems.

We can't cange that because that breaks existing passphrases. For new
installations it should not be a problem becuase modern systems are all UTF-8
(modulo Windows)

I wonder if it is an encoding problem.

0.9.7 released.

When this feature becomes available, then we should probably disable
"gtk-entry-password-hint-timeout". See the following Debian bug report for details:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801757

Ready for implementation by Andre.

Thanks for your feedback.
I was wondering specifically about the use-case when you want to enter
and "ok" the passphrase. The regular flow for this as I understand it would=
be

  typing the passphrase and then "enter" or "return"

I think it is okay to have "tab" cycle between options, but including the=20
option of toggling visibility, because somebody who want to enter the=20
passphrase would (in my understand) always do the above flow and not=20
tab-tab-enter.

pinentry-gtk-2 does currently support the tab-tab-enter use case. Using 0.9.6-4
from debian, i can use tab to cycle between the textentry dialog and cancel and OK.

I see the same behavior from pinentry-gnome3 (0.9.6-4), tab workflow is:

• textentry
• Cancel
• OK

for pinentry-qt (same version as tested above) the tab ordering is:

• textentry
• OK
• Cancel

That said, i agree that i'm the only person who has raised this, and i'm
perfectly willing to be retrained to use more efficient keyboard flows if
they're presented to me. So if you want to go ahead with the current plan,
that's fine with me.

I agree that consistency with common UI patterns on the platform of choice are
worth emulating -- we don't need to invent or maintain our own UI patterns that
are idiosyncratic to GnuPG.

(2nd try, the mailinterface failed for me.)

http://www.aelog.org/password-visibility-in-kpassworddialog/

Good that you found it.
In the comments Bogdan has a point.
The screenshots also do not look convincing, but I agree it makes sense to be
consistent there. Could we also get a screenshot about this implementation
for Windows 8 they are talking about?

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

As gtk-pinentry

1. currently does not allow tab-return
2. and it does not make sense as a workflow
3. we are lacking further evidence if there are users that still use this for a password entry. (Not response by dkg.)

I'd say the discussion on the mailinglist is fully superceded.

In my view we should
a) design it close to pinentry-qt, because it also will be used on Windows

mostly and the consistency with other Windows password dialogs has a lot of 
weight

b) Look at other wide spread gtk-dialog for this functionality and use

   the better design considerin Bogdans comment with a "switch".

The icon could possibly used in both implementations. (If the license allows
this. Oxygen used to have a bit less practical licene coming with it.)

Best,
Bernhar

Bernhard:

I've tried out KDE 5 and noticed that the standard password dialog there already
has such an option. http://www.aelog.org/password-visibility-in-kpassworddialog/

My strong preference for Pinentry-qt would be to make it similar. As a unified
UI adds value and pinentry-qt is afail most often used with Windows and KDE
desktops. And the solution outlined in the link above is also very similar to
the Windows 10 password entry.

For GTK we should implement it the way werner has outlined and as has been
discussed on the mailing list. So that users with more "Keyboard centric"
workflow have the GTK alternative available.

Would this be acceptable for you?

Werner, I know that nothing much in pinentry has changed since 0.9.6 but this
bug is pretty bad for pinentry-qt. It would be good to have a new release.

Given that this bug does not appear to be reproducable with 0.9.6, I'm marking
this as resolved.

Keep the bug open. We won't fix it for the next release.

werner: What is your call to action? Should pinentry always be shutdown or is
the status quo acceptable? Thanks.

@dkg,
what do you think about T2139 (bernhard on Nov 02 2015, 10:09 AM / Roundup)?

I'm marking this as resolved as the currently released version of pinentry
compiles with gcc-5.1

dkg: No worries. Thanks for testing.

I've just tested 0.9.6 using the same procedure as T1777 (dkg on May 14 2015, 12:01 AM / Roundup), and i have no
problem entering text either. I think this is resolved. sorry for the delay in
feedback.

It would nice to have an exactly sequence of commands that cause this problem.

Given the amount of time since the request for testing, I don't think we are
going to get a response. As such, I'm going to close this issue and mark it as
resolved. If there is still a problem please either reopen this bug report or
file a one. Thanks.

I'm marking this as resolved. If it is still an issue, please feel free to
reopen. Thanks.

Hi!

@dkg:
Can you tell me more about your tab-return use case? Do you have hints/personal
observations about how many people are affected?
In the gtk2 pinentry this did not work so far (See my T2139 (bernhard on Oct 29 2015, 04:42 PM / Roundup)) other
implementation do not seem to allow it (I've also tested kdm login screen)
and it does not make much sense either when you can press "return" right away.
So to me it is still unclear how many people are affected.

@aheinecke: Thanks for contributing another case.
I think it is a good solution for a system login screen, where a login-change
probably is harder to do.
I think this slightly changes when you think about passphrases for pinentry
that may get entered less often and some people keep a backup on paper (which is
actually good under some circumstances) and I would claim that a passphrase
change on a key on average is easier to do than a system password.

@werner: You wrote that you've checked some other implementation, it would be cool
to have a list of those. Screenshots would be even better.

@all, my current design ideas are

• to have a text below the entry field, close to it, saying "show password" and a on-off switch or second best a check-box, third best a button.

Rationale: Because the space requirement is mainly in width. An on-off switch

probably has the most natural mapping, but this depend on the overal GUI design
of the system. On some a real slider-switch may not be available or look alien,
then we should use what ever users will recognise as an on-off thing.
The text is much less work than to select/design an icon and it uses
less height.

• It is okay to have that in the accessibility tab list, even after the entry field, because I personally believe that a lot more people want the natural order when using tab at all. Right now the data for how many people actually have the tab-enter habit is unknown, maybe Daniel can help us out here.

Btw. The Windows 10 login screen implements this as a button that you can not
tab to and only shows the password for as long as you keep clicking it.
It also disables / hides the show password button once the password entry field
loses input focus.

They use a heavily abstracted eye icon and no tooltip. Probably with the
rationale that if a user clicks there and it shows the password
(unintentionally) he can quickly release the mouse button again before someone
can read the password.

On Thu 2015-10-29 04:34:03 -0400, Bernhard Reiter via BTS wrote:

@dkg: I have been thinking about your use case:

I wonder about what fraction of people we are speaking of.
In many applications, just like pinentry, you can just hit "enter" right away
so there is no need to first hit "tab". First hitting "tab" does not make sense
for these kind of dialoges.

Then in some implementation like pinentry-gtk2 0.8.3-2,
this does not work right now, because the next tab is "cancel" which users then
would reach. So it depends on the standard for dialog windows where the
ok and cancel buttons are. Was there any problem report on pinentry-gtk-2?
I am not sure if any pinentry-gtk-2 user actually had this problem?

Daniel:
Thanks for your comment and adding the use case. I saw your suggestions
on the list like changing the tab order.

More specifically: Would it be fine with you to implement this without
a warning dialog that requires another click or attention?

Some people are used to pinentry and have a common keyboard-based type, tab, hit
enter workflow.

Please make sure that this workflow doesn't accidentally switch their password
to visible when this change is implemented.

My suggestion is also, to seek for an icon that is more self-explanatory.
Actually I would like the "gtk_switch" gui component, though Werner is right
that it takes up a bit more of space.

Uh that's an embarassing error.

Thanks for your analysis and fix. I haven't seen problems with this in my tests
but the UTF8 Byte array is indeed temporary and the pin pointer is invalid after
it's destruction.

I've commited the your fix (with an ammended commit message so it confirms to
the msg style used in pinentry) with f143d21

Werner I've assigned it to you as this needs a release :/ Sorry.

ah, it seems there is a slightly different coding style. adjusted.

D335: 698_0001-Keep-a-reference-to-the-pin-when-converting-it-from-.patch

Here's the patch

D336: 697_0001-Keep-a-reference-to-the-pin-when-converting-it-from-.patch

An option to explicitly disable qt5 was added as part of T2105

Thanks. I can confirm the issue being fixed, although I have only tested with
Qt4 (which this bug report is against, anyway.)

I probably need to get hacking on pinentry again, though, because your latest
changes do not allow explicit selection of Qt4 xor Qt5 and thus lead to
non-reproducible builds...

looks good to me

Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./test.sh
#!/bin/bash
have_qt5_libs="no";
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./test.sh
no
./test.sh: line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/pinentry/files/pinentry-0.9.6-add-disable-pinentry-qt5-option.patch#n38
which doesn't experience this issue.

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in
testing

Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.