thanks for your reply
gpg -K
gpg: enabled debug flags: memstat
/home/usernet/.gnupg/pubring.kbx
uid [ absoluta ]
uid [ absoluta ]
ssb cv25519 2022-02-13 [E]
gpg -h
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

It is a bit hard for us to decipher the Spanish diagnostics. Before we can try to help you please update to a deent version of gpg and libgcrypt. At least the version for Ubuntu is way too old; Libgcrypt is 5 years old, the current version of the lTS branch is 1.8.10. GnuPG is also 10 years old and in the mean time we have fixed several critical bugs; the current version of this legacy branch is 2.2.41! Note that Ubuntu might have fixed some bugs despit ethe version number - we just can't know.

Fixed in 1.10.2.

Thank you.
Applied to both (master and 1.10).

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);

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.

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.

After consulting with our certs lab and studying the code I think SHAKE should not be a problem for now. All of the _gcry_digest_spec_shakeXXX seem to neither have an mdlen nor a read() function. pk_sign and pk_verify seem to both call md_read() which should fail because of the missing read function, kdf checks _gcry_md_get_algo_dlen() which should also disallow SHAKE.

Good catch. A similar problem might arise with SHA384 according to section D.R which states

One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:

These look good to me.

Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:

This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.

Patch lets it build on xenial for me, thank you.

Patch for this bug is available here, "attachment-0001.bin": https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005079.html

I committed the partial result docker container, so I can restart it for investigation. So:

I tested xenial with gcc-5.3 (xenial distro repo) and gcc-5.4 (xenial-updates distro repo) and libgcrypt 1.9.0 from git repo and from tarball. I did not get any errors.

Closing due to compiler error.

I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:

With an integer overflow.

This is a standard dynamic sized array:

Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).

At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.

Maybe casting to a void* helps to disable the check in the compiler.

I can replicate the issue on my system.
It is not the line 681, actually.

I think that the problem is in your usage with your tool. Please have a look at md_open function in cipher/md.c.
This bug is not the one in libgcrypt, but in the compiler.

Same argument can apply to MD5. See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int' of SHA2.

See T3245: cipher-gcm-intel-pclmul.c:418:17: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long').

See T3248: mpiutil.c:501:37: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' for unsigned integer overflow.

It is intentionally used.
And in the C programming language, it is defined that unsigned integer never overflows (it is computed as modulo 2).

See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int'.

Hello. Please note that this is a bug tracker and not a support forum. Nevertheless, let's investigate.

The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.

Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:

Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
given.

This will also help us address issue #1827.

0.9.6 will be release today, thus I close it.

GNOME--

It's not crashing for me with master but its not fixed.

I acidentally ran into this while checking out a windows crash and found the cause:
echo $GPG_AGENT_INFO /run/user/1000/keyring-Lvs93w/gpg:0:1

At least this was my problem and as "Ubuntu" is the platform it is likely that
this was the original problem.

I've commented in the launchpad report.

This is likely fixed in 0.9.5 release Sep 1.

Please provide a proper test case which is independent of the
distribution. Do not report distribution specific problems to an
upstream package. Thanks.

This has already been fixed in the trunk. I just backported it to 1.4 and 2.0.
(svn rev 5361).

That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.

From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).

Done for 2.0 in svn r5082; will also be packaged with gnupg 1.4.10.

We can't print an error message because that would let gpg treturn with an error
code and lead to problesm with scripts which assume the current way of doing
things. A warning is possible but Unix tools generally don't do that.

Fixed in SVN. Thanks.

The first part is not easy to fix and would require quite some rework. I don't
think this is justified.

Forget the second part. It prints this message only, if it indeed needs input
and giving --yes works in this case too. So there was a fault on my side.

Maybe we misunderstood(?). The gpg-agent is not used.