Please provide the debug output, so that I can see which encoding was used to decode the error message.

In T5960#175302, @ebo wrote:

Found in GnuPG-VS-Desktop-3.2.0-beta178, broken ü and no linebreaks:

Setting this to high after consultation with @werner, these issues should be fixed in next release.

Found in GnuPG-VS-Desktop-3.2.0-beta178, broken ü and no linebreaks:

This is hopefully resolved. Setting to done because the fix cannot be verified with our builds of Kleopatra.

It also doesn't occur with the AppImage (Do we build a debug or unoptimized build for the AppImage?).

The problem doesn't occur with the development build. It also doesn't seem to occur with our Windows build.

Well 5.4.2 o.O and we on Tumbleweed are at 13.x gcc

I found this in the change log of Qt 5.4.2:

- On x86 and x86-64 systems with ELF binaries (especially Linux), due to
  a new optimization in GCC 5.x in combination with a recent version of
  GNU binutils, compiling Qt applications with -fPIE is no longer
  enough with GCC 5.x. Applications now need to be compiled with
  the -fPIC option if Qt's option "reduce relocations" is active. For
  backward compatibility only, Qt accepts the use of -fPIE for GCC 4.x
  versions.
  Note that Clang is known to generate incompatible code even with -fPIC if
  the -flto option is active.

This should be in the newest for testing.

So I think that the problem here is that ArchLinux either does not build Qt6 with -fPIC or it does and others don't and that our check for wether or not to add -fPIC is not really working as it should. When compiling executables we should also add -fPIE instead of -fPIC.

So by we already have code to handle this problem, we had code for "No body but multipart/mixed" and your message was "empty body but multipart mixed" so I just needed to also check for an empty body and the code worked.

Ah damn, now that I closed this as a duplicate I found that we already have code to handle this problem.

I found this related to that: https://sourceware.org/bugzilla/show_bug.cgi?id=28875

I have analyzed this. In the ribbon we get a mailitem OOM object as reference, but that can be a different pointer then the one we used for decryption / verification. Our trick for this was to assign mailitems a custom uuid property and then look for that from the riboon pointer so that we can update accoringly with our internal Mail object representation.

Fixed. I'll copy the ideas in comment T6698#175165 to a separate task.

At least GnuPG only shows the most recent key signature tag. So if we leave it out when adding another signature then we remove this.

Yes remove this / leave this empty. I think the idea was that if you certify lots of users and wanted to have the same tag. But I guess that would be covered by bulk signing anyway and can actually be more trouble if you accidentally use the wrong tag.

Compiles for me, too with Qt 6.5.2 from tumbleweed.