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.

"Revoke certificate" is now available in the "Certificates" menu and the context menu in the certificate list. Don't confuse it with the "Revoke certification" entry. ;-) Maybe we should reword "Revoke certification" even if for me it says exactly what it does.