The reported issue is definitively fixed, didn't test the rest yet

The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

Pushed the change not including OK_TO_CHANGE_ERROR_BEHAVIOR part.
Note that the modification affects main key case, too.

works

I suppose this means that, optionally, the certification should expire at the same date/time as the current validity of the certificate. Or shall this be a configurable fixed validity period of certifications?

As far as I understand the problem, all content-ids are lost during processing of an email.
This process happens during the signing/encryption of an email.

Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.

A starting point for this could be:

Werner mentioned that the keyword "qual" can also be used like the "relax" keyword can also be used in the global trustlist.txt

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Eva this is a bit related to the certification documentation and we talked about this last week.

Thank you for you responses! :)

I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.

tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.

That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.

To minimize the impact of the change, I updated:

diff --git a/g10/import.c b/g10/import.c
index 1ed40a63c..345e8cc75 100644
--- a/g10/import.c
+++ b/g10/import.c
@@ -2955,9 +2955,23 @@ do_transfer (ctrl_t ctrl, kbnode_t keyblock, PKT_public_key *pk,
 {
   gpg_error_t err;
   struct import_stats_s subkey_stats = {0};
+  int force = 0;
+  int already_exist = agent_probe_secret_key (ctrl, pk);
+
+#ifndef OK_TO_CHANGE_ERROR_BEHAVIOR
+  if (already_exist == 1)
+    return gpg_error (GPG_ERR_EEXIST);
+#endif
+  if (already_exist == 2)
+    {
+      if (!opt.quiet)
+        log_info (_("key %s: card reference is overridden by key material\n"),
+                  keystr_from_pk (pk));
+      force = 1;
+    }

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

works

Changes may be something like:

diff --git a/g10/import.c b/g10/import.c
index 1ed40a63c..91ff0c8ec 100644
--- a/g10/import.c
+++ b/g10/import.c
@@ -2706,6 +2706,20 @@ transfer_secret_keys (ctrl_t ctrl, struct import_stats_s *stats,
           goto leave;
         }

gpg_encrypt (engine-gpg.c) passes --output - to gpg, i.e. it reads the result of gpg --encrypt from stdout unless I misread this. Not sure, why this seems to work on Windows. The real problem is probably something completely different.

isn't T3456 the same issue?