I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):

Thanks! Verified this builds on aarch64 correctly and generates the right flags on the output:

Hardened: /builddir/build/BUILDROOT/libgcrypt-1.11.0-3.el10.aarch64/usr/lib64/libgcrypt.so.20.5.0: Overall: PASS.

Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.

Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:

Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html

I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.

Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.

Thank you for having a look into this!

Oh, I did not notice the change as I clicked to the patch from mail notification. Trying now with the updated one:

Running scratch build on s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=119376728 with the proposed change. The failure is now:

Thank you for having a look into that. If I see right, Fedora has a real s390 hardware for builders so I can verify the fix when available.

I left review comments in gitlab.

In T7129#186556, @werner wrote:

In PATCH GnuPG 12/15] sm: Avoid use of uninitialized variable I can't see where ERR was not initialized.

Fair enough. This is more theoretical and could happen only on huge reads. Using ssize_t for read() return value is safe option, but really does not make sense to adhere to it in cases where the reads must be smaller.

Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.

The report went like this

Error: OVERRUN (CWE-119):
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:303: cond_at_most: Checking "plen > 8U" implies that "plen" may be up to 8 on the false branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:305: cond_between: Checking "plen" implies that "plen" is between 1 and 8 (inclusive) on the true branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:309: assignment: Assigning: "i" = "0".
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:310: overrun-local: Overrunning array "t" of 16 bytes at byte offset 16 using index "8U + plen + i" (which evaluates to 16).
#  308|   
#  309|                 for (i = 0; i < 16 - (8+plen); i++)
#  310|->                 if (t[8+plen+i])
#  311|                     {
#  312|                       err = GPG_ERR_CHECKSUM;

but looking again, it is wrong as it did not reflect the end condition for the cycle, which obviously means the cycle does not run. Sorry for the noise.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

For the reference, for now i just did the dummy install in the Fedora spec file:

Nope, The gpgconf --kill keyboxd hangs too, if I see right, while waiting for agent:

$ strace gpgconf --kill keyboxd
[...]
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2d74fe2a10) = 3244
wait4(3244, 0x7ffc9836e364, 0, NULL)    = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

From the FIPS 186-5 there are some limitations to use the SHAKE in FIPS Mode that we will have to reflect:

Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?

Another approach would be having "non-hash" algo for gcry_md_open.

FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:

Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:

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.

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.

In regards to this issue, we were also notified that the MD API using gcry_md_setkey() can be used to calculate HMACs and it does not have the needed input key length limitation. From the discussion here I read that we would like to keep the internal usage still available so my proposal would be to to add similar check as in gcry_mac_setkey() into the above function. Together with the revert, it is available in the following merge request:

In T6039#164435, @gniibe wrote:

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

One more nit regarding to the test is the format string for size_t which was using %d instead of %zu. This is fixed by the attached patch:

I tried to clarify the comment in the following merge request. Feel free to pull it from there or adjust if it is too verbose or missing some points:

In rCa6a6e94027abf18a51f5f93bf9fb2cfe5496bdf8#74835, @werner wrote:

Why is that not stated in my man page which knows about kernel 3.19? Is that a regression or a RedHat specific patch?

One nit that I overlooked initially is the memory leak, which is fixed with the following patch:

The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:

The test looks good. I hope I changed the API in all the hw optimized implementations.

This still did not seem to help me in making the tests working on Fedora with git master. I am still getting wrong paths to the gpgconf

gpgscm: error running '/root/gnupg/tests/tools/gpgconf': probably not installed

There is a full reproducer and more complete log in https://bugzilla.redhat.com/show_bug.cgi?id=2089075#c11

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

For the record, the changeset in the attached merge request is final and waiting for reviews.

The provided change does not look like fixing the problem for me. The path to gpgconf is still wrong and I am getting the same error both with master and with the patched tarballs:

make[2]: Entering directory '/home/jjelen/devel/gnupg/tests/tpm2dtests'
LC_ALL=C EXEEXT= PATH="../gpgscm:/home/jjelen/.local/bin:/home/jjelen/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin" abs_top_srcdir="/home/jjelen/devel/gnupg" objdir="/home/jjelen/devel/gnupg" TPMSERVER="" SWTPM="/bin/swtpm" SWTPM_IOCTL="/bin/swtpm_ioctl" GNUPG_BUILD_ROOT="/home/jjelen/devel/gnupg/tests" GPGSCM_PATH="/home/jjelen/devel/gnupg/tests/gpgscm" /home/jjelen/devel/gnupg/tests/gpgscm/gpgscm \
  /home/jjelen/devel/gnupg/tests/tpm2dtests/run-tests.scm  
gpgscm: error running '/home/jjelen/devel/gnupg/tests/tools/gpgconf': probably not installed
(wait-process "/home/jjelen/devel/gnupg/tests/tools/gpgconf" 2693795 #t): Configuration error

AFAIK the above case has a lot of wiggle room to fit one PID and the surrounded string into 400 bytes and even if it would need to truncate, it would write terminating character, at least on Linux:

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

I was pointed by Daiki to the following patch in Fedora binutils, which allows listing the fdo packaging metadata, but it does not list any other unknown objects and unfortunately fails hard:

I have one follow-up is that the readelf chokes on the integrity note for some reason:

$ readelf -n /usr/lib64/libgcrypt.so.20.4.1
Displaying notes found in: .note.fdo.integrity
  Owner                Data size 	Description
  FDO                  0x00000020	Unknown note type: (0x8e2afeca)

I assume this is just because the readelf does not know this type. I see this type was initially proposed by Daiki, but I did not find any other sources for this magic number so before filling bugs for readelf, do we have some doc why the 0xcafe2a8e is used?

Adding

GPG_TTY=$(tty)
export GPG_TTY

makes this working so thank you for the pointer.

the -v does not show more useful info on the gpg side:

# gpg2 --quick-gen-key admin
About to create a key for:
    "admin"

You are combining two concepts here -- the KDF and the AEAD cipher itself (at least from the FIPS terminology). I would like to avoid mixing these two together in the new API. If you would like to implement the SSH/TLS KDF, I would suggest to use the kdf API you already have. Then we are here left only with a new geniv API to implement. In the T4873 I mentioned example how it is now used in libssh using libgcrypt, which implements the iv increment outside of the libgcrypt:

The mails from these days still contain the following header:

List-Post: <mailto:gnupg-devel@lists.gnupg.org>

which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?

I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.

For the record, there is a new report on the mailing list about this module on MacOS:

Thanks. Looks good to me.

In T5512#153650, @Jakuje wrote:

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

libgcrypt-fips-indicator-kdf.patch3 KBDownload

I went through the documentation related to FIPS and updated some wording to match reality. It will probably require still some more work.

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.