There is another hacker working on finishing it. I only provided the framework.

@werner will have to answer why he added the unfinished code. My guess is that he wanted to prevent it from being lost on his computer. I would probably have deactivated the code as long as it's unfinished.

For the next release T5842 (so with a higher priority) I have picked

Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.

For our internal tests this boils down to testing:

• with keyboard only
• for people using a screenreader
• with 400 % magnification
• with high contrast color scheme
• with inverted color scheme

My direct problem is to silence warnings for newer GCC.

What is the problem here? Some compiler warning about fully legal code?

Ah! Sorry! Is there any reason the command-line flag made it to a release? How should the user know that the feature does not work, other than reading the bugtracker and source code?

You are trying to use unfinished code. See https://dev.gnupg.org/rGafe5fcda52e88438c7a7278117b2e03f510a9c1c. It's not really surprising that unfinished code doesn't work.

I tested encrypt two txt files with filename 1 and 2.txt and insert text: test 1 and test 2. Tararchive has been created successfull. Than i tested this Two txt files with a long name. See attached txt files, i send it already to you. Now by the first test Archive.tar.gpg.yqoirl with 0 Bytes was created.
Second test, the other archive.tar.gpg with 0 Bytes was created and gpgex hang.

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.