I'd prefer to not use the spawn helper at all. All currrent Windows versions allow to decide which handles are to be inherited and thus there is no more need for the helper.

As discussed in chat has nothing to do with only signing. Only that signing makes it easier to get errors by cancelling pinentry or entering bad passwords.

You are creating a signed archiv? Why - gpgtar is used for encryption.

I reprodcued this with a simple: "gpgtar --status-fd 2 --verbose --create --sign -u foo@bar vimfiles > foo.tar.gpg" on the command line. Which gives me the proper status lines but then ends up in kleo with general error.

I tested it some more. Gpgtar reports proper erors like:

Ok closing, remaining issue is in T6813

After reading the initial description of this, I think that might even be a yet a different bug. For which we then would not yet have a ticket. :)

The issue for that is: https://dev.gnupg.org/T6566 so I think this can be resolved here?

No it is just not properly selected after generation but it is there. I think there might even be an issue for that already. But definitely not something related to vsd 3.2

With VS-Desktop-3.1.90.277-Beta the generated key is the default RSA 3072.

That sounds very good.

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.