We have the same patch (including the hmac key and we use the switch. The reasoning on our side was to be compatible with fipscheck, but it is no longer used since last year and we use just the hmac256 tool:

Just for the records, the whole HMAC thing including the special dlopen trick used to work fine when we did the original FIPS support.

Right. The clarification is that SHA1 itself (for non-security and non-signature use) is still allowed in FIPS mode. But it is not allowed to be used as part of signature schemes of the new API in FIPS mode. The old API, which allows raw signatures without digests, should just fail in FIPS mode too. And the FIPS-compatible gnupg should use the new API too (it would be good to think about this when putting it together).

For Linux and FIPS, we should be actually fine with using /dev/random or getrandom().

I added some asserts. However I doubt that it can be hit by LibKSBA. I also fixed a real bug related to VALTYPE_BOOL - but that is also not used in Libksba.

The CAVS driver can be safely removed. The certification goes through the ACVP these days so it does not make sense to keep this.

For use of SHA-1:

I have done tests with 2.2 and no problems showed up.

(can't access that bug with my account)

For tests with FIPS mode enabled, I manually create the file .libgcrypt.so.20.hmac under src/.libs.

I pushed my further change.
Also, applied and pushed your changes.

Sorry, I didn't test for non-FIPS mode when I committed rC347817438990: fips: Fix tests in fips mode..
Tweaking the value for memory allocation is needed for FIPS mode, because it uses some secure memory by DRBG.

I went a bit back to the history to figure out what is the enforced and soft fips mode as it was initially not completely clear to me. For the record, I used the following bug from 9 years ago:

Tested the master on (faked) FIPS and non-FIPS Fedora and I created couple of more changes for master to work in FIPS mode:

keyserver hkps://hkps.pool.sks-keyservers.net:80 is problematic.

Since I think there is no reason why checking _gcry_enforced_fips_mode () here, I remove the check.

Did you restart dirmngr? ("gpgconf --kill dirmngr" so it will be started on demand).

Applied by rC0f118c2dfb8e: cipher: Do not use of non-approved digests in FIPS mode.

debug network,dns,ipc
log-file C:\Users\Administrator\dirmgr.log

I wrote this in my dirmngr.conf. But i haven't found this .log file.

There are two things here.
(1) Use of [] (FLEXIBLE_ARRAY_MEMBER)
(2) Use of offsetof (instead of sizeof) for computation of size of allocation.

Based on the info about this being caused by the added support of PIV, I poked around on the docs at https://gnupg.org/documentation/manuals/gnupg/gpg_002dcard.html and noticed the disable-application stuff. I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

At first I've had simply tried to give multiple --symmetric options (which of course didn't work).