In 1.9.0 we already have the include functional in threadedjobmixin ( 60064c665ec98a2a994fc6c8ad701e60b963ce7e )

I've accidentally pushed this commit. But I'm very sure it's Ok anyway and pretty trivial. And it's been over a month to object. I really need this patch to get keygen working with default_pubkey_algo in kleopatra. It was also included in the last gpg4win betas.

I think we are talking "aneinander vorbei". AFAIK we agreed (on the Osnabrück meeting) that we will cater to this usecase: Multiple different keyrings for some operations. Or "curated" keyring. Through GPGK and so we will have some API (key probably not a keyring for a context) like this in GPGME at some point in the next years. This is why I think this issue might be kept open to say: Yes we see the usecase but we will not solve it by exposing, what you call a hack, through GPGME. But we will solve it at some point with a better solution.

FWIW I strongly disagree with the sentiment that GPGME should be a "dumbed down" "Easy" GnuPG API. It should be GnuPG made stable -> A stable and reliable C API for the Free Software OpenPGP implementation GnuPG. But this is off topic. SCNR. It's much easier just to use process calls in many cases but I understand why this should not be done and leads to maintenance problems / bugs.

As discussed: The proper solution for this is GPGK, a Pubkey deaemon for GnuPG that would cater to audited / monitored keyrings. The usecase has not gone away and from my talks with people in the community and my general experience it is not "special" and definitely not "very special". It's important for Software Developers using GPGME that want to have keyrings for their Software Seperate from the general GnuPG user setup.

Assigned to werner as the corresponding differential is waiting review and a general look at how we do ldap fetching on windows is also best done by werner.

beta232 has some basic compliance support mainly missing is Compliance indication for crypto operations (encrypt / decrypt / sign /verify)

Ok I think I understand it better now. The problem is not with the email-ca file (that explains why the test works) but appears to be in the ldap fetching code which is different on Windows. Even if we loaded the CRL for the root CA previously dirmngr still fetches it over LDAP and tries to parse it. This parsing of the root ca's crl is what fails.
Under GNU/Linux the dirmngr_ldap wrapper is used (at least on my system) while for windows since 2.1 we use the ldap-wrapper-ce.

Talked to Werner about this. He still has concerns that this is wrong because an application should not do globbing itself and only changing this in gpg.exe is inconsistent. It also might be a security problem as most users won't use the double dash to seperate arguments from filenames.

Added this to 3.0 because I don't want to release any known crashes.

I just commited the fix I had in gpg4win 2e71bf3. I don't see how this is objectionable as it changes the behavior back to what we had before we switched to building on jessie and is a minor ifdef.

With Gpg4win 3.0 Kleopatra's startup procedure is much more robust. You can try https://wiki.gnupg.org/Gpg4win/Testversions and please report if the issue still persists.

I accepted the patch so this ticket should have been resolved. Sorry.

Emanuel please add release gpg4win 3.0 as a parent task if you think we should fix this before 3.0. I'm unsure.

I'm very sure this is no longer an issue.

With Gpg4win-3.0 ( https://wiki.gnupg.org/Gpg4win/Testversions ) Kleopatra is a completely different beast and I think this is fixed. I've tried it in various setups with Virtual Machines running for a long time and never had this problem anymore.

Will be released with 3.0

This was fixed since. Fix will be released with gpg4win 3.0

We no longer use Kleopatra for status in our supported versions (OL >2010). So resolved.

With Gpg4win 3.0 we have reworked the startup of Kleopatra. It is now much more robust. Please try https://wiki.gnupg.org/GpgOL/Development/Testversions and reopen this issue / comment if this is still a problem.

Kleopatra no longer polls gpg-agent it queries the smartcard status once at startup and then only if you open the "Manage Smartcards" menu. So I think this is fixed (gpg4win-3.0)

This is fixed in gpgol master.

I still wonder how to handle killing gpg-agent on update on Windows.