It seems you have replaced the scdaemon module from GnuPG by a 3rd party module (which exhibits a version number 0.10.0) - this is not supported and you will of course run into errors.

What you uploaded are files with a length of zero bytes. That is not valid data. The hang should not happen of course.

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.

It should not really hurt to query the scdaemon again after an import. We can do this in the background and users wont have to notice it in the general case where imports from others happen.

In https://wald.intevation.org/forum/forum.php?thread_id=2395&forum_id=21&group_id=11 "Kim Nilsson on 2022-02-15 16:48" reports that

I wonder why a platform has no cmp but comes with printf, which is a modern POSIX extension to Unix.

Thank you for your suggestion.

I simplified the script not to use cmp: rC3c8b6c4a9cad: fips: Fix gen-note-integrity.sh script not to use cmp utility.
And I clarified the semantics of the integrity check.

Ah, right, I can get that added to the containers tomorrow.

I located the cause:

../../src/gen-note-integrity.sh: line 78: cmp: command not found

Yeah, please do issue a new release as soon as possible if you can, as otherwise downstream we're in an awkward position where we have to rebuild everything without a SONAME bump, then do it again once the release is out.

@werner Please release a gpgme-1.17.1 with

diff --git a/configure.ac b/configure.ac
index f6d4b50e..57e6ea2e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -64,8 +64,8 @@ LIBGPGMEPP_LT_CURRENT=20
 LIBGPGMEPP_LT_AGE=14
 LIBGPGMEPP_LT_REVISION=0

That only seems to work in some configurations: https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/pipelines/472626834

The actual problem isn't the removed internal symbols, but

'method virtual QGpgME::KeyForMailboxJob* QGpgME::Protocol::keyForMailboxJob() const' has some sub-type changes:
  the vtable offset of method virtual QGpgME::KeyForMailboxJob* QGpgME::Protocol::keyForMailboxJob() const changed from 28 to 31
    note that this is an ABI incompatible change to the vtable of class QGpgME::Protocol

KMail calls keyForMailboxJob(), but because of the changed index in the vtable it called addUserIDJob() which ultimately caused the crash.

Why can't we hide internal symbols in c++ as we are doing in other libs for ages? Were the internal symbols only accidentally exposed?

I pushed the change: rCa340e9803882: fips: More portable integrity check.
It uses .note.fdo.integrity section, not loaded onto memory.
It simplifies the logic, and switches to dladdr (from dladdr1).

Pushed the change which fixes the build with ld.gold.
rC9dcf9305962b: fips: Integrity check improvement, with only loadable segments.

Thank you for your suggestions, @werner.
I agree that we should not put much effort to develop our own methodology here; Too much effort may introduce possibility of unmaintainable code, which should be avoided for the particular purpose of "integrity".

Sure. We'll bump the SONAME.

In T5834#154975, @ikloecker wrote:

I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.

FWIW, the internal class in question was completely rewritten. Since the damage has been done already, I'll close this report. We won't readd symbols to dead code. Sorry, for the inconvenience.

Folks, you are opening a can of worms. The only secure why to sign a file is to have a detached signature. That is often non-practical and thus putting the signature/MAC at one certain position and exempt just this one position from hashing is the next best alternative. Any more complicated rules will inevitably introduce security flaws. If a binary is stripped, it is a different binary than a non-stripped one, if it is linked with another linker, it is a different one. And that binary will even be able to figure this out and change behavior. Please keep it simple.

Thanks! Maybe it would be simpler to use dl_iterate_phdr(3) for this. I wasn't aware of the function, but a colleague just implemented a proof-of-concept of what you're proposing in https://gitlab.com/dueno/integrity-notes.

I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.

I am going to apply https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/64ccc25c4b4a2c8c4e13e7e37ff1c8c60a3d8401
And consider adding the code to limit hashing content (from start of the file to end of data section).

Guess why GnuPG has its own Tor aware resolver ;-) To debug this kind of stuff you need to debug dirmngr, by adding for example

Found it: I did not initialize gpgme_op_interact's last parameter out with gpgme_data_new. The error is now gone.

As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.

Instead of extending the context menu I have simply added a button next to the fingerprint which always copies the fingerprint without whitespace to the clipboard. Should also be better for accessibility.