Change the encryption code to only allow 256 bit session keys with Kyber regardless of the preferences, iff --require-pqc-encryption is set. […] We could as well also encforce AES-256 also without that option.
What if we encrypt to several recipients, only some of them having a Kyber encryption key? Should we still enforce AES-256 in that case regardless of the preferences, and assume that by now everybody should support AES-256?
Love it! I think I am going to use “post-heffalump crypto” from now on. :D
I wrote it with PQC security level in mind which requires AES256 for the session key as well.
Here you are:
With no scd-event script, it might improve the situation
I don’t think I have any other client that would invoke SCD DEVINFO --watch.
Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?
Which version of Scute are you using?
I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)
Finally had some time to look into this a bit more.
A better solution could always be found later
Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)
In T5551#148510, @werner wrote:I would prefer to see a fix/hack in pinentry-qt instead.
the t-link test should dlopen scute.so in runtime rather than link against it in build-time.
The built file is called scute instead of libscute because it is considered to be a *module*, not a *library*. That’s apparently a Debian thing, see commit dc2211179ea7f63434d726eefbc425390c4c6427.
It should be fixed with 49ad2b0e05e3fcb8c8c2e23bb1c6063b390dee02, though I don’t have a gcc-10 to check. It does work with gcc-9.3 with -fno-common.
Fixed with commit 4d95b7457d62bf785a2157bb2cfa002bde7ff8f5. It turned out the test the convert was already there, but its result was not used to decide whether to build the doc or not.
I agree about checking for convert (but maybe just skip building the doc instead of aborting everything if convert cannot be found).
Thanks @aheinecke for fixing my fix with 2859edd! Closing here.
There’s a patch to restore support for Qt4: D521.
My bad, prior to the release I tested only against Qt5.
Looking at the backlog of pinentry-related issues, I don’t think that would warrant delaying further the release of pinentry-1.1.1, especially given that the last release was 3 years ago already. Remaining issues (most of them being stalled anyway) or feature requests can be postponed for a future pinentry-1.2.0.
The fix will be part of the upcoming pinentry-1.1.1.
Any news about this bug? It has been in “Testing” for quite a while now. For what it’s worth, handling of ^C seems to work here as I would expect, so I am inclined to close here and let pinentry-1.1.1 go out. @gniibe, as you did the fix, do you have any comment?
No disagreement after more than a year, I think it’s fair to say that either everybody is fine with that feature being only present in the -qt, -tqt, -gtk, and -curses pinentries, or that nobody cares. :) Closing now, will be part of the upcoming pinentry-1.1.1.
The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.
I could not reproduce such a failure either under any conditions.
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.
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.
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.
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.
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).
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.
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.
Okay, so maybe this has nothing to do with T3748 then…
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).
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.
@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.
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.
The problem seems to have to do with the locking of the TOFU database.
Still trying to pinpoint the bug, but I am afraid I am stuck.
I did a few more tests and here are some more observations:
So… Is there any interest in the approach I drafted in D442?