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.

--debug-pinentry is an option for the gpg-agent. Thus put the line

debug-pinentry

into gpg-agent.conf and make sure that there is also a log-file option.

I compiled pinentry version 0.9.5 and tried to regenerate my keys. The good news
is that the curses window appeared and I could enter my passphrase. The bad news
is that after I entered the passphrase(with the repetition), the program
freezed, not returning any prompt and not giving any sign of life(I checked with
top to be sure and nothing).

Also, when I tried to use the --debug-pinentry, gpg didn't recognize it as a
valid argument. I use gpg 2.1.6.

D295: 667_0002-enforce-std-gnu-11-to-avoid-breakage-with-gcc5.patch

the attached patch is a minimal patch to make older versions of pinentry-qt4
build cleanly with newer gcc.

Please update to pinentry 0.95 and try again. You may also use the gpg-agent
option --debug-pinentry which shows the communication between gpg-agent and
pinentry.

pinentry-curses 0.9.1

Which pinentry version are you using?

This will be fixed in the upcoming pinentry release as pinentry-qt no longer
uses std::string

gpg-agent requires that you add
--enable-emacs-pinentry.
to gpgagent.con. This is similar to
--no-allow-external-cache
but even not enabled by default.

Thanks for testing this!

@neal. Just pulled master and gave it a try. Role is correct, events are correct,
and Orca's working as expected with that widget. Thanks much!!

This was done with 26ab44b.

I'm now using pinentry-qt5 as my main pinentry but I doubt that there will be
any problems. After dropping the "Secure widgets" There were no code changes
necessary to support Qt5.

Duplicate of T2057

Duplicate of T2058

Duplicate of T2059

The documentation part of this bug should now be resolved. There are three
other issues. I've opened separate issues in the tracker for them.

I've added some documentation. Let me know if it needs further improvement.
Thanks.

I replaced our custom entry widget with the standard Gtk+ widget. This makes
the changes to the secure entry redundant. I did apply the tooltip changes
(c9c3576) and the gtk_widget_get_window changed (70a106) from your patch. Thanks.

I replaced our custom entry widget with the standard Gtk+ widget. This should
fix this problem. Please test and let me know either way. Thanks!

I replaced our custom entry widget with the standard Gtk+ widget. This should
fix this problem. Please test and let me know either way. Thanks!

Hi, I've just replaced the use of our custom entry widget with the standard Gtk+
entry widget. This should fix the problem. Please report back whether this is
the case. Thanks.

Thanks for the feedback. Closing.

0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch - on top

optional

sync qt4 pkg-config behaviour

D317: 660_0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch

0002-build-use-pkg.m4-for-pkg-config-usage.patch - on top

remove the manual pkg-config usage, as build already use pkg.m4 macros there is
no reason to use manual pkg-config