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.

The rationale behind this was that it should just compile with Qt > 4.4 and take
the newest version available. But yes with Qt packaging in different names
between 4 and 5 etc. I can see that this can be problematic.

With: 08ec9556c8a384ea7bb5d42d3f6aab6c2f6a8786 I've added an option
"disable-pinentry-qt5" to explicitly disable looking for qt5.

Does this solve your problem?

ciil: Thanks for the update!

0.9.6 has meanwhile been released - any news?

0.9.6 has been released - does it work?

All of the pinentry's use the same metric, which is very naive. From
agent/call-pinentry.c:

/* Estimate the quality of the passphrase PW and return a value in the

range 0..100.  */

static int
estimate_passphrase_quality (const char *pw)
{

  int goodlength = opt.min_passphrase_len + opt.min_passphrase_len/3;
  int length;
  const char *s;

  if (goodlength < 1)
    return 0;

  for (length = 0, s = pw; *s; s++)
    if (!spacep (s))
      length ++;

  if (length > goodlength)
    return 100;
  return ((length*10) / goodlength)*10;

}

Sorry for not having provided more information earlier. The bug seemed to only appear
on my work machine (and I've been to busy at work the last few weeks to provide more
information), but now I can reliably reproduce it on my home machine, too, funnily
enough after a clean re-install of Arch Linux.

It certainly seems to be the same bug as the Gentoo bug #560158 you linked. I cannot
reproduce the behavior in either gdb or valgrind, but without those the command fails
every time.

I've since downloaded and manually built 0.9.5 and 0.9.6. I could reproduce it in the
standalone 0.9.5 build (again, neither valgrind nor gdb could be coerced into also
showing the behavior. The issue seems to be fixed in 0.9.6, though! Arch doesn't yet
provide the new version as an official package. I'll tell you if the issue's also fixed
when that package comes out.

Still have no idea what caused it though.

Kristian Fiskerstrand pointed out that there is more information about this bug
at: https://bugs.gentoo.org/show_bug.cgi?id=560158

I am pretty sure this should be fixed with the current master version of pinentry.

This version does no longer use the std::string stuff as it uses the usual qt
widgets.

Feel free to reopen this bug but I am so sure about it that I'll mark it as
resolved now :-)

Hi Neal, you are right about the entropy. I tought it was gpg but I think it's
because my system is too minimal to produce enough entropy. I finally decided to
generate my keys in another machine and transfer them to my minimal
installation. Now it works perfectly, with pinentry 0.9.5.

Thanks for your help,

Regards,

Felix

I can't reproduce this. I'm using pinentry 0.9.5 and GnuPG from git. When I
generate a key, it talks nearly 3 minutes for GnuPG to gather the required
amount of entropy, but it eventually returns. Attaching to gpg-agent using gdb,
it appears that gpg-agent is "suck" in the generate key function:

  #9  0x00007f13a08da9ce in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #10 0x00007f13a08ca2db in gcry_pk_genkey ()
     from /lib/x86_64-linux-gnu/libgcrypt.so.20
  (gdb) 
  #11 0x000000000041f51f in agent_genkey (ctrl=0x1b69e80, cache_nonce=0x0, 
      keyparam=0x7f1398001e70 "(genkey(rsa(nbits 4:1024)))", keyparamlen=27, 
      no_protection=0, override_passphrase=0x0, preset=0, outbuf=0x7f139fccfdb0)
      at ../../../gnupg/agent/genkey.c:479
  479	  rc = gcry_pk_genkey (&s_key, s_keyparam );

So, I seriously doubt that this is a problem with pinentry. And also I doubt
that it is a problem with GnuPG. Most likely, you need to wait for the system
to generate more entropy.

If you think gpg or gpg-agent is really hung, it would be nice if you could use
gdb to attach and then get a backtrace and post that here.

Thanks!

Neal

Thanks for the report. I'm having trouble reproducing this. I run pinentry
(from the build directory) as follows:

  $ valgrind gtk+-2/pinentry-gtk-2
  ==3611== Memcheck, a memory error detector
  ==3611== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==3611== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
  ==3611== Command: gtk+-2/pinentry-gtk-2
  ==3611== 
  OK Pleased to meet you
  getpin
  D 012345678901234567890
  OK

I enter a 21 character password and pinentry doesn't crash and valgrind doesn't
report any error. I tried with both 0.9.5 and the latest version from git.

Are you able to reproduce the problem using the above method? Can you provide
an example of how to cause the crash using only pinentry?

Thanks.

Here is the content of my gpg-agent.conf:
debug-pinentry
log-file /home/fxleblanc/gpg-errors.txt
pinentry-program /usr/bin/pinentry-curses

Here is the content of my log file:
gpg: reading options from '/home/fxleblanc/.gnupg/gpg.conf'
gpg (GnuPG) 2.1.6; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat
trust hashing cardio ipc clock lookup extprog

gpg: signal Interrupt caught ... exiting

I interrupted the program because it wasn't doing anything after I entered my
passphrase.