I just ran into this, too, on macOS.

Fixed in 1.10.2.

In T6388#168750, @gniibe wrote:

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.

Fixed in master and 1.10 branch.

Your quick support solve my problem, I am thanking you :)
Bye bye

I added a remark to the print function. Thanks for the suggestion.

You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".

Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

Pushed the change.

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

Thank you for the bug report.

@gniibe: Would you mind to look at this?

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

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

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

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.

Agreed

I think the patch is okay.

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.

Thanks

Well, I do not yet see a use case for this. The current rush towards PQC makes it unlikely that newer curves will get in widespread use. Iff we have a large application which requires this curves, we can reconsider,

Sorry, but we can't check all parameters. Why only check that one and not the others or invalid values for ctx. You may do such checks in an interactive environment but not for a general library.

See T6340 in case of build problems.

Thank you for your reply! I'll modify my testcase

I figured out the situation.

Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.

Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.

When I look at the stack information, I find that because E->p is not assigned in the function mpi_ec_get_elliptic_curve(), this produces a null pointer，but it didn't get to the branch : if (errc) goto leave;

If you pass NULL to that function, the calling code is wrong. No need for an explicit check in nomralize - check should be done in the public API (if at all).

I tried to fix the segmentation fault, so I added a null pointer check at the end to protect it.

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Well, the modern way, recommended by the FSFE, for license notices in source files is SPDX instead of verbose license notices. https://reuse.software/

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

I put rCc34c9e70055e: fips: Mark AES key wrapping as approved. under this task, so that it can be referred in the release note.

Let me describe the changes recorded in this task.

Thanks. There should also be SPDX indentifiers everywhere.