For anyone stumbling across this issue I created a docker image containing gpg with the patch above applied: https://github.com/smlx/gnupg-piv-agent

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:

We once figured that we should use this for gpgme, where we use a helper to close handles. We have not yet found the time to do this and frankly "never change a running system" ;-) We also still support Windows XP SP3 with GnuPG for users with air-gaped machines. Not sure whether this is still justified, though.

The reason for this is probably that we expect that several UIDs are added and running a check-trustdb for eachleads to some extra waiting time.

I just copied the value of 0xcafe2a8e and the name .note.fdo.integrity from Daiki's implementation. No other reason.

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?

Have you selected an Output file in a location where you can write files with your permissions?

I had already tried both, to deselct all other add-ins and to select all possible add-ins.
No change of the behaviour.

Could you please create a log file using the debug settings with Outlook Object Model debugging enabled?

We should give this higher priority as users need to change their e-mail through kleopatra. A customer also wishes this.

I think that good approach as of 2022 is:

libgpg-error 1.45 is out with the fix.

Updated the copy on our mirror as welll as the gpg4win and swdb packages files.

The set_bit is obvious but we should cross check with the specs. In the non-fips mode we also try w/o a limit.

I think that it is OK to loop forever until we find a prime.

I don't know the exact procedure by FIPS, but just setting the least significant bit in the generation (after _gcry_mpi_randomize) can reduce the probability by half.

The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)

Sorry, that was a misunderstanding. My fault.