This has already been fixed with rM4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e

Frankly, I don fully understand your report. Can you please clarify?
Note that with 2.2.8 we introduced full Unicode support on the command line. If you see scrambled output you may want to "chcp 65001" to get the output correctly rendered.

I have recently been busy with the new features and mechanisms of the GpgFrontend project.

iirc Uli Drepper added a hack to dladdr which we made use of. Seems to be integrated into dladdr1 now.

In T5436#148656, @cnp1234 wrote:

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.

While I don't know if runtime integrity check is required or not by FIPS 140,
I checked OpenSSL, and it has such a check in openssl/providers/fips. The FIPS module configuration file which has the module checksum by HMAC is generated by openssl fipsinstall command.

Ah... I realized that HMAC integrity check with dladdr (using address of constant string) might work (at some point) to determine the filename of libgcrypt.so, when/if glibc implementation allows searching with address of constant string. So, my claim "never worked" was wrong.

I have added shortcuts to the checkboxes and the (first) visible filename requester. I have not added shortcuts to the two buttons because the first one is anyway the default button, i.e. it reacts on Return, and the Cancel button reacts on Esc.

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.