The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.
Sep 15 2019
Sep 13 2019
Sep 11 2019
I could not reproduce such a failure either under any conditions.
Sep 9 2019
With the build problem on Mac OS now fixed with d551cf9, barring any last minute issue I plan to do the actual release by the end of the day tomorrow (10 September).
If I understand correctly, the problem stems from the -module flag added to the LDFLAGS in commit dc2211179. It's that flag that instruct libtool to create a bundle (.so file) instead of a dynamically linked shared library (.dylib file). But that flag is needed to force automake to accept that the library is to be named scute instead of libscute (without that flag automake errors out, complaining that scute.la is not a standard libtool library name).
I just checked that Scute builds cleanly on Slackware, Debian, and in a cross-compilation setup against Mingw32.
Aug 28 2019
For information, I can’t reproduce here, either with GnuPG 2.2.17 / Pinentry 1.1.0 or with a fresh build from the tip of the master branches. Both pinentry-tty and pinentry-curses prompt for the password as expected, independently of whether the file to decrypt is specified as an argument or sent through standard input.
Jun 8 2019
If I understand correctly, this is exactly the same problem that the one we encountered some time ago in the code dealing with fetching keys from HTTP (--fetch-keys), and that we fixed with this patch.
Feb 13 2019
Since it seems there is a renewed interest in adding ECC support to GpgSM (as indicated by the T4098 feature request), I would like to write down here more details about this task.
Feb 12 2019
Pinentry already has a ttyalert option which may be set to beep or flash to ring the bell or flash the terminal, respectively (see commit 1dba96fafa123f3631c0a50bb01835306c23b903).
Feb 11 2019
Regarding the quality evaluation, several months ago I proposed to optionally delegate that task to an external tool (specified by a new gpg-agent option passphrase-checker). I posted a first draft as D442 and then submitted a proper patchset to gnupg-devel, but although @werner expressed interest it was never merged. I have just checked that the patchset still applies cleanly to both the master branch and the STABLE-BRANCH-2-2. I can re-submit it to the mailing list if needed.
Feb 10 2019
I have updated Pinentry’s configure script to support the --disable-doc option, as it is indeed supported in other GnuPG components.
Patch applied, thanks.
Patch applied, thanks.
Feb 8 2019
Dec 25 2018
Aug 23 2018
Aug 15 2018
Aug 6 2018
Jun 8 2018
May 30 2018
May 14 2018
Okay, so maybe this has nothing to do with T3748 then…
May 11 2018
If you never explicitly changed the default trust model, then I would expect you are not using TOFU, but the presence of a tofu.db file strongly suggests that you are indeed using it.
This looks reminiscent of a bug previously seen in GPA (T3748).
Apr 16 2018
Thanks @werner for applying the patch. Closing here, since I have been using that patch for several weeks now without ever encountering the bug again.
Apr 13 2018
@dkg : Can’t this be solved at the distribution level? I assume the packager/maintainer for Libgcrypt on a given distribution should know whether the getrandom syscall is available on said distribution, so he could install a /etc/gcrypt/random.conf file with the only-urandom option.
Feb 20 2018
Bissecting between gnupg-2.3-base and master pinpointed commit ecbbafb88d920e713439b6b1b8e1b41a6f8d0e38 as the origin of the bug. This commit changed MAX_FINGERPRINT_LEN from 20 to 32, but the get_user_id_byfpr function in g10/getkey.c still assumes the old value.
Feb 19 2018
The problem seems to have to do with the locking of the TOFU database.
Feb 16 2018
Still trying to pinpoint the bug, but I am afraid I am stuck.
Jan 29 2018
I did a few more tests and here are some more observations:
Jan 18 2018
Dec 29 2017
So… Is there any interest in the approach I drafted in D442?
Nov 22 2017
Nov 16 2017
Oct 29 2017
OK, the problem with D450 lies in the way the value obtained from clock_gettime(2) is used.
Oct 28 2017
It turns out I cannot reproduce the bug with a 4.13.2 kernel. Whatever happened to times in slightly older kernels when VIRT_CPU_ACCOUNTING_GEN was enabled seems to have been fixed in newer kernels.
Oct 26 2017
The Linux specific solution in /D450 looks like a good solution but it needs some testing.
Sep 1 2017
Could you expand on this slightly?
Aug 25 2017
OK, thanks for the info.
Aug 24 2017
Avoid moving the window ourselves if the cursor happens to be on the same monitor than the currently focused window, since in that case the window will already be on the right monitor.
I am not sure I agree with the “cryptic error message” bit. I would think anyone knowledgeable enough to play with LC_ALL (or any other LC_* variable) should understand what “a locale function failed” means and conclude that maybe the best way to fix the problem is to leave LC_ALL alone.
Aug 23 2017
Is this even something that we can control?
I just realized that my fix for T3253 was incomplete, it only works if grabbing is enabled. With GnuPG Agent not requesting grabbing by default since 2.1.23, that would make the fix useless in the default configuration. Coming with a new patch soon...
Aug 21 2017
I suspect this is a duplicate of T3253, where the same behavior (non-floating pinentry dialog) was observed under both the i3 and the Awesome tiling window managers. This bug has been fixed in master and the fix will be part of the upcoming pinentry-1.1.0 release.
Aug 7 2017
Free the memory allocated by the gnupg_exec_tool call (sorry about that...).
Aug 6 2017
I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.
Me personally I see T2103 as more pressing blocker to next release
Aug 4 2017
Aug 3 2017
Leave the tooltips in place but show them only if do not have to grab the keyboard. As suggested in the discussion in T3279.
Jul 24 2017
Well, I am using pinentry-gtk2 1.0.0 on Awesome, and I just performed some tests with master as well.
Jul 14 2017
Is this correct?
Jul 13 2017
I can reproduce the described behavior. I have a 4.11.7 kernel with NO_HZ_IDLE=y and everything works fine, but if I set VIRT_CPU_ACCOUNTING_GEN (all other options remaining unchanged), the agent is stuck in the calibration loop (tested with GnuPG 2.1.21 and current master branch).
Jul 12 2017
I've just pushed the two fixes. GNUPGHOME is now set to the tests directory when running the tests and gpg-connect-agent is now looked for in PATH at runtime.
Jul 11 2017
All build artifacts are accessible
Jul 7 2017
OK, I pushed my fix into master.
Jul 6 2017
Since there is no news for the last two weeks, I am wondering: am I the one blocking the situation here? Are you waiting for me to do something to make progress?
Jul 5 2017
I can confirm this behavior with the latest pinentry-gtk-2 under the Awesome window manager.
Jul 3 2017
The cause of the regression may actually not be in GnuPG's code.
Jul 2 2017
For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.
Jul 1 2017
or am i missing something here?
Jun 23 2017
Yes, I am ready to accept write access to the Scute repository.
Jun 22 2017
I think the best method to make sure Scute can always find the socket is to use gpg-connect-agent to ask for the socket: we call gpg-connect-agent 'GETINFO socket_name' /bye and read the reply.