Plan: Use the table only for X509 add an entry field above for OpenPGP Keyserver.

Found the problem and fixed it. The Problem is described in the commit. Basically glib always assumed it gets UTF-8 Encoded filenames even if they were provided in system locale through double click / open with / command line / drag & drop.

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

You can now install Gpg4win with /S /MINIMAL=1 command line switches to just get gnupg + pinentries. I think this is what enigmail needs.

Installation of Gpg4win is now possible without Administrator rights. GpgEX does not handle it yet but this is another issue. GpgOL / Kleo / GPA and GnuPG work. Including file extension handling.

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.

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.

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.

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)

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

Thanks for looking into it but sadly this did not fix the problem. I'll try to attach a debugger or trace with printf tomorrow where libksba thinks the CRL is invalid and how this differs from the success case with t-crl-parser.
So I'm claiming this task again for that.
But I also think that a unit test that does an S/MIME import / trustlist change / CRL Imports and then an encryption without crl-checks disabled would be useful.

This is what I noticed. This patch makes dirmngr and t-crl-parser both use same reader:

I don't think that is the case because the CRL works on Linux and t-crl-parser from libksba correctly parses the crl on both Windows and Linux.

I manually parse email-ca-2013.crl:

On Windows I can reproduce the problem this way:

Before the gpg-agent is started you need to create a file trustlist.txt:

Let's create a test case that demonstrates the problem. Andre, is it ok to include your certificate in the test suite? How can I mark the root certificate as trusted without pinentry interaction?

GPG_ERR_INV_CRL_OBJ is only possible by libksba.
I'd suggest enabling debug option for dirmngr by .gnupg/dirmngr.conf:

log-file SOMEWHERE
debug-level {basic,advanced,expert,guru} # Chose one
debug-all

to investigate what's going on.

Yes I see this behavior on Linux, too (needs two tries). I have not yet reported a specific issue but this as it does not hurt my usecase (Kleopatra / GpgOL) because there you are asked when you import the key / when a keylist --with-validation is done if you want to trust the root certificate. Which happens before the certificate is used in an operation.
The problem for me is that CRL checks, at least against our current CRL fail (on windows) but not on linux.

Ok, after adding allow-mark-trusted and configuring a pinentry, I get a failure once, a second try succeeds:

Note: This is Windows only!

For me it fails a bit differently:

To make this more precise I think above might actually be more then one bug.

Yeah I broke that by fixing GnuPG to output Console Encoding. Kleo uses Qt
::fromLocal8Bit which expects the GUI CP.

Messy stuff, need to figure out how to get the ACP through Qt or the QT Name of
the console codepage for conversion. This not only here but everywhere where
Kleo shows GnuPG's console output. There are also some bugs about this at
bugs.kde.org.

We have seen this today also in another Kleoptra warning box. The text was not
localized but the error description (from gpg-error) had a broken Umlaut.

Andre?

I've tried latest master and it no longer hangs for me.

Thanks. Changing the status to not-released as this is fixed.

I just tested it with gpg4win3.0.0-beta215

gpgsm -v --output Downloads\kitten.gpg --recipient jochen@intevation.de

Downloads\kitten.jpg

gpgsm: certificate #13/CN=Email CA 2013,O=Intevation GmbH,C=DE
gpgsm: Die CRL konnte nicht geprüft werden: Ungültiges CRL Objekt
gpgsm: Benutztes Gültigkeitsmodell: Schale
gpgsm: Hinweis: Verschlüsselung für `jochen@intevation.de' wird nicht

möglich sein: Ungültiges CRL Objekt

    gpgsm: Ungültiger Befehl (Es gibt keinen implizierten Befehl)

So the CRL file was not automatically pulled via console either.

This was with gnupg 2.1.19 I think it's a duplicate of T2984 if the CRL
can't be loaded sending an S/MIME mail will fail.

I tried it on two different autohrities.

https://ssl.intevation.de/:

    gpgsm -v --import F:\zertifikate\SMIME\emailca2013.crl
    gpgsm: no issuer found in certificate
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: no issuer found in certificate
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: ksba_cert_hash failed: Kein Wert
    ksba: ber-decoder: node `?': TLV length too large
    gpgsm: gesamte verarbeitete Anzahl: 2
    gpgsm:                        nicht importiert: 2

https://www.rz.uni-osnabrueck.de/dienste/unios_ca/index.html:

    gpgsm -v --import Downloads\cacrl.crl
    gpgsm: unknown hash algorithm '?'
    gpgsm: certificate has a BAD signature: Allgemeiner Fehler
    gpgsm: Grundlegende Zertifikatprüfungen fehlgeschlagen - nicht importiert
    gpgsm: gesamte verarbeitete Anzahl: 1
    gpgsm:                        nicht importiert: 1

Seem to be different errors, but it doesnt work from command-line, too.

But the error from the front-end is different, when I tried importing via
commandline first:

Beim Importieren der Sperrliste ist ein Fehler aufgetreten. Die Ausgabe von

GpgSM lautet:

gpgsm: unsupported inquiry 'SENDCERT_SKI

93E3D83226DAD5F14AA5914AE0EA4BE2A20CCFE1 /CN=DFN-Verein Certification Authority
2,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE'

    gpgsm: response of dirmngr: Unbekanntes IPC "Inquire"

The error is the same for both CAs (except tfor the inquiry details).