No. Windows has a file selection dialog where you can only select files and a folder selection dialog where you can only select folders. We cannot change Windows (and we will not use a non-native file dialog).

This is a serious regression.

With the latest change the output read directly from gpg should now be displayed correctly.

As far as I can tell and see with my limited tests, everything works (for me). There's nothing else I can do and I don't have the slightest clue why it seems to fail sometimes. Somebody else needs to take over.

With regard to invalid characters in error messages as in T5960#172860:
We are using the identical function everywhere to convert the error codes to text. If an invalid character is displayed if copying a key to a smart card failed, then invalid characters should also be displayed for example if one tries to decrypt something in the notepad without having the necessary secret key. I get "Kein geheimer Schlüssel" in this case, i.e. no invalid character.

The remaining problem with output that's read directly from a GnuPG process seems to be that sometimes gpgconf --show-codepages prints 0 as ConsoleOutputCodePage or even as ACP (as in T5960#175580).

I tried to reproduce this with a locally built gpg4win-4.2.1-beta56. Using localhost as keyserver I got (after a looooooong timeout)

Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

In T5960#175407, @ebo wrote:

The result of your changes is a bit unexpected for me, maybe something is missing in the testversion Gpg4win-4.2.1-beta31?

[6064] org.kde.pim.libkleo: gpgConfGetConsoleOutputCodePage returns 65001
[6064] org.kde.pim.libkleo: stringFromGpgOutput trying to decode "" using codepage 65001

I think using a static const char * is better than using a macro. In fact, using a static constexpr std::string may be even better because we avoid calculating the string length during runtime again and again. (I'm not sure the compiler is clever enough to precalculate the string length of a static const char *.)

In T6556#175399, @werner wrote:

@iklocker: Which gpg bug to you mean?

Then gettext_use_utf8 doesn't seem to be working as intended.

Hopefully, we will soon have a Windows CI to catch such errors.

Also, please retest T5960#172860 with the latest build.

The previous two changes will hopefully fix the error output of export to server. I'm not entirely sure about the missing line breaks.

With regard to the ü-error in the error message on keytocard somebody else has to check what's going wrong because I'm convinced that we are doing everything right.

The debug output of libkleo is missing. Please add org.kde.pim.libkleo.debug=true to your qtlogging.ini.

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.

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.

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.

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

Fixed. Backport? (Depends on first preparations for bulk certification and is probably not really relevant for VSD.)

The official build for Arch Linux doesn't seem to run into this problem. The Qt6 build is configured with

./configure \
  --prefix=/usr \
  --disable-fd-passing \
  --disable-static \
  --disable-gpgsm-test \
  --enable-languages=cpp,qt6

See https://archlinux.org/packages/core/x86_64/gpgme/