Thanks for your answer

Ok
Thanks for your answer

I'm not sure that I understand your Problem. It might be helpful if you could provide screenshots of your problem so that we can better understand it.

We are not a CA and do not provide certificates.

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?

With certified keys the automation is working as expected.

Got a new OL 2013 test setup where this was finally reproducible for me.

Last week:

Last week:

• FST-01SZ design ordered for prototype (only 10 pcs).

OK, I take this ticket.

Discussion on the #python IRC channel last night with another experienced SWIG developer (of a proprietary and unnamed software project) has provided ass itional evidence supporting the theory that the cause of the problems with getting the bindings to run on Windows systems is indeed directly caused by the fact that Windows users are compiling GPGME and the bindings with a different compiler and runtime than those used to compile whichever version of Python they have obtained from elsewhere.

Well, I have already tried to explain the use case: To make using cryptography easier for our users (for most of them the command line is the hell ...) I have integrated GnuPG in our webmailer. The webmailer has a key management page where you can import and export keys (up- and download, import from mail, attach to mail etc.), where you can edit trust settings, and where you can sign other keys and revoke such signatures. The webmailer certainly does not offer all capabilities of GnuPG but certainly a substantial subset.

The option you mean is "Disable non-blocking encrypt / sign", correct?
It's english in the german dialogue, btw.

Thanks for the tests and the report.

This seems very special and I'm not sure if we should not say at some point that we won't add quick commands for everything ;-)

The crash on send should be avoidable by checking "Disable async encryption" in the options.
Yesterday I got a new OL 2013 test system with which I can reproduce the crash. So that will be fixed or worked around for the next release.

no. Outlook 2013 reproducably crashes on sending and won't toggle
encryption on.

Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise

Actually i have now more debug output and i think i found the issue

I close this for now, this seems a problem of the mingw packages in msys2

ping, what's the status of this bug? it has been in testing for over one year. is that the correct status?

Sure, this should work, local keys are preferred.

But can't I simply use the keys in my local keyring?

No you can not use an "external" Web Key Directory. The point is that the provider (your domain) should be the source of the keys as it already manages the mail account. ( For more info see: https://wiki.gnupg.org/WKD )

Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.

I downloaded GPGwin v3.1.3 beta 20 today. The automatic key fetching fails in my case because we have no WKS. Never heard of that before.

Or with both packages installed, could i maybe debug somehow where it searches?

BenM, msys2 uses pacman as packagemanager, all packages are build from source

There is the same bug and fix in function parse_key :

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 0d28e7ac1..b147179e2 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -2533,7 +2533,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen,
                      err = gpg_error (GPG_ERR_INV_PACKET);
                      goto leave;
                    }
-                 ski->s2k.count = iobuf_get (inp);
+                 ski->s2k.count = iobuf_get_noeof (inp);
                  pktlen--;
                  if (list_mode)
                    es_fprintf (listfp, "\tprotect count: %lu (%lu)\n",

I misunderstood your original report.