We are now generating a key with whatever defaults gpg uses.

Well I guess T6805 is now the followup ticket that I did not create when I just closed this issue as Wontfix. Ingo can you take T6805 and do what you wrote in your last message here?

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

We don't use or suggest the use of PIP or other insecure software distribution systems.

It works, thanks!

Should work now. Please test if the auto-detection works. (Tumbleweed builds Qt 6 without "reduce-relocations", so that I cannot check it on my system.)

Small correction: On my/our system (Tumbleweed) the test without -fPIC always succeeded, so that -fPIC was never added. That's why I removed this useless test which, as it turns out, wasn't useless on your distro (@dfaure-kdab Which distro are you using?).

Thanks for creating the task.

There should not be an exception "Invalid crypto engine" in that call. I expect that gnupg errors out immediately if the parameter with tofu is given while instead it should print a warning and show no information. Or of it errors then Invalid Crypto Engine is definitely the wrong error for that.

I did this locally:

--- a/lang/python/tests/support.py
+++ b/lang/python/tests/support.py
@@ -46,13 +46,15 @@ def is_gpg_version(version):

A quick test shows that the latest patches allow to set and show an expiration date beyond 2038. A new VSD beta will soon be available to customers. And we should also think about getting a gpg4win bug fix release out.

In T6767#177126, @werner wrote:

Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?

yes, fixed

I think this was fixed with the fix for https://dev.gnupg.org/T6534

Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?

Here's a patch that should fix this. It's not amazing since we have to copy the map_w32_to_errno from libgpg-error, as it's not public API there.

Since @ebo did not really know how to test I just checked that it is passed to gpg to resolve this issue.

C++ bindings also done.

Core part done.

After the fix everything after the Signature block is now silently discarded

works

Tested in VS-Desktop-3.2.0.0-beta214 by encrypting a large file with Kleopatra. The progress bar shows percentage finished, progress looks all right

Re-open to add auto-detection.

Relevant lines from Arch's qconfig.pri:

QT.global.enabled_features = shared pkg-config rpath reduce_relocations signaling_nan zstd thread future concurrent dbus openssl-linked opensslv30 shared shared rpath reduce_exports no_direct_extern_access reduce_relocations openssl
QT.global.disabled_features = static cross_compile debug_and_release separate_debug_info appstore-compliant simulator_and_device force_asserts framework c++20 c++2a c++2b c++2b wasm-simd128 wasm-exceptions opensslv11
QT.global.disabled_features += release build_all
QT_CONFIG += shared rpath reduce_exports no_direct_extern_access reduce_relocations openssl release
CONFIG +=  shared plugin_manifest

Per IRC discussion, this could be autodetected in qt6.m4 by querying Qt6Platform.pc for mkspecsdir and grepping ${mkspecsdir}/qconfig.pri for QT_CONFIG.*no_direct_extern_access.

No need for QA on build issues.

The Qt 6 bindings will now be compiled with the -mno-direct-extern-access flag if --enable-no-direct-extern-access is passed to configure.

In T6696#175866, @antonio-rojas wrote:

This is a Qt issue. Reported at https://bugreports.qt.io/browse/QTBUG-117398

This is a Qt issue. Reported at https://bugreports.qt.io/browse/QTBUG-117398

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

Yes the error message is better now. In German it is "Entschlüsseln fehlgeschlagen: Fehlerhafte Daten." Which could be a bit more clear, but its ok

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.

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.

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.

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

Compiles for me, too with Qt 6.5.2 from tumbleweed.

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/

This is now mostly done. These 3 patches make it work:

Nevermind we clarified in chat that we would instead deprecate this API.

Kleopatra doesn't rely on the defaults in the library and other users shouldn't either. I would kill defaultkeygenerationjob. And it's use in newkeyapprovaldialog should be fixed, e.g. by using QuickJob::startCreate().

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.

Done. Will be tested with T5903: Kleopatra: Add refresh button in certificatedetails .

Minor correction of the interface changes:

qt: toLogString                            NEW.