This pretty much highlights a general problem of groups: If the distribution groups for the email client are managed independently from the certificate groups then there will inevitably be discrepancies. The obvious solution is the usage of groups managed by a central service for email addresses and certificates. (Or an encrypted mailing list service.)

Applied your patch (from gitlab) to both (master and 1.10).

Applied to both (1.10 and master).

You are right, there is no way to use DRBG with SHA384 by libgcrypt.

Applied to both (1.10 and master).

Applied to both (of 1.10 and master).

Thank you!

Right, thanks for the review! Updated patches below.

Actually, the same issue is in the mac case, which I missed on first couple of reviews:

-  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);
+  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_mac_algos);

Looks like the TERM alacritty was the culprit, I'm ssh'ing into the freebsd machine from my archlinux laptop.

We discussed this further with the lab and there are more problematic flags that we need to "cut" and we can not do that always in the code as for example the RFC6979 (deterministic ECDSA signatures) are not allowed in the current version of the FIPS documents, but it is used in the selftests (which is weirdly enough allowed) so we just need to mark it unapproved. Lets discuss this further tomorrow.

Going through the code once more, there is one typo to be fixed:

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);

should say

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_md_algos);

otherwise ack.

I don't know what is going here really. I have installed alacritty and I can reproduce T4924 easily if I provide an empty passphrase on an narrow window. At least I get pinentry-curses popping up.

@ikloecker not sure we are there yet. I was able to set a weak password on a terminal that was 42 characters wide. I think the problem here is unrelated to FreeBSD but to the fact that @capitol uses alacritty https://github.com/alacritty/alacritty

If agent_write_shadow_key does now also check for an existing private key file, then I'd replace following code in cmd_readkey:

if (agent_key_available (grip))
  {
    /* Shadow-key is not available in our key storage.  */
    rc = agent_write_shadow_key (0, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }
else
  {
    /* Shadow-key is available in our key storage but ne check
     * whether we need to update it with a new display-s/n or
     * whatever.  */
    rc = agent_write_shadow_key (1, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }

with a simple call of agent_write_shadow_key (removing the maybe_update flag) and let agent_write_shadow_key do all checking for an already existing private key file and whether it's a stub file that needs updating.

Could this be a duplicate of T4924: pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals?

I think we should make it explicit - this will be safer. As of now agent_write_shadow_key will do a check only in its special update mode which should be okay for now.

I can't see any explicit thing there.

$term is 'alacritty', stty -a is:

speed 38400 baud; 54 rows; 180 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

The agent.log says that the error comes from pinentry-curses:

Hi, thanks for the quick turnaround

I tried to reproduce on my FreeBSD 14 machine and didn't get an error....

Make sure that the fix doesn't break "gpg --edit-key; keytocard; save" which explicitly does replace the private key with a stub file.

That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.

I doubt that the bug is only in 2.2. The code in 2.4 is different but it may happen there anyway. It depends on the usage pattern.

(That's actually an old ticket but we still open)

@werner Seeing as you seem to be actively maintaining this project: is there any way to move this forward? This is breaking quite a few builds of development environments for my company and we are now applying similar patches ourselves but it would be nice to get this merged upstream.

@bnavigator Would it be possible to also add support for 3.11 and 3.12 here? That way this fix is a lot more futureproof.

Thanks for the description; this is good for documentation.

Note that for the OpenPGP implementations which use X25519 API, it is not possible to calculate [scalar]G with scalar having least significant three bits != 0.

(my example cert is 0x09BB0EEE)

That sounds like a great (and better) solution! Thank you for your attention & effort 👍🙏

See T6395 for the new feature. It will be released with 2.4.1 but it will take some time that it can actually be used because the other party needs to have an OpenPG implementation which supports this.

Agreed

I think the patch is okay.

It might be related to the GPGME test failure we had related to that. But I thought this was fixed in GnuPG.

Added SETQUALITYBAR support with some fixes for glitches when an error string was set. Wide characters seem to work OK.

Just had a look at the development version. There the observation is exactly the opposite, i.e. the Tags columns of the certificate list and of the user ID list are empty, but the tags are shown in the Tags column of the certifications list.

We came to the same conclusion -- the SHAKE digests are not usable for sign/verify operations the way how it is implemented now. But it would be more clear if we would have explicit allow-list.