Ping. Is this patch ok? I'm pretty sure it is and I've included it in Gpg4win but before I can push the default_pubkey_algo respecting change to Kleopatra I need this to work in GPGME.

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.

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.

On Windows I can reproduce the problem this way:

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

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.

Note: This is Windows only!

Accidentally marked this as resolved when I only wanted to update the status.

As a first version you can now apply profiles in Kleopatra. It also respects the default_pubkey_algo_name and shows in tooltips / certificate details if a certificate is compliant.

Patch now fixes the problem in gpgme

Update diff with arcanist

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

Mh as I already pushed this I guess I should now commandeer it and then abandon it.

Applied with 5d4f977dac542340c877fdd4b1304fa8f6e058e6

2e661b9e1a9b50656a5c9646d7444a98477010c1

5faddcb2927a997e05fb34eb270982096d1fe3a4

4644c27514f34f5efc555d43672a25088a611a72

ea079d283de6bf4ac70d7530fac70938e7c5e8f5

a6fcdbc9e0fc0e45a3badc23813e689e83059b61

5e1a844ae9b6730b4b8a2c9178ea9bc121560c28

I don't remember if this was submitted but it works now.

We have something like that now. :-)

Werner fixed this differently but it's fixed.

Submitted I think, or a different variant of it.

Yeah! Love this patch. Was submitted.

Submitted.

Abandoned.

This was submitted.

This was submitted.

Submittted

This one is submitted in slightly different form.

Fixed that through white-listing the status instead of blacklisting errors.

This was already commited in a modified form.

Then please fix that. TBH I find it annoying that you did not check that your
commit actually solves the problem. I mean just using the "stable" branch would
have been enough to see that.

It's important that GPGME builds / runs against all versions of GnuPG and most
distros treat test failures as build failures. Now 1.9 will again need patches
or the python bindings disabled which is creating unnecessary work downstream
which already had enough work with the recent releases.

Yep

I've rebased the patches against 1.8.0 but I still saw 22 failing python tests
with 2.0.26

Master fails for me even harder with 36 tests failing.

The gpg-connect-agent call's fail because --agent-program is not supported. In
master we even have --debug-quick-random which is even more recent (but which we
would also need in random starved environments like build daemons)

My preferred solution at this point would be to just say for 2.0.x the python
tests are unsupported and disabled completely. All the problems are with our
agent setup regarding the test suite and not really with functionality.

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.

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

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

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.

Thomas confirmed this, with our workaround for the SNI problem removed the
problem still occurs. We have activated our workaround again to keep wks working
on testkolab.

I think gniibe may have posted a related patch to gnupg-devel some time ago not
to abort on non fatal GNUTLS alerts but I don't think it was applied.

This issue does not have high priority for me so I downgraded to minor bug but
it's still an issue.

With this patch the log message is different (No such file or directory). Hang
still happens.

2017-03-03 10:21:06 scdaemon[8604] DBG: enter: apdu_get_status: slot=0 hang=0
2017-03-03 10:21:06 scdaemon[8604] DBG: leave: apdu_get_status => sw=0x0 status=7
2017-03-03 10:21:06 scdaemon[8604] npth_pselect failed: No such file or
directory - waiting 1s

Version was 2.1.19 from the installer built by werner / the speedo system.

I'll try out the patch

From T2833 (wk on Mar 02 2017, 07:49 PM / Roundup) I don't think the problem is resolved. Yes it works now with
gnutls and ntbtls because we fixed / changed it on our side. There were no
changes to the GnuTLS code regarding alerts afaik.

Thomas: I've assigned this now to "no-selection" if possible I would have
assigned it to you. Can you come up with a test / demo that shows that this
problem still exists. Something werner could test against?

Thanks for your report. Indeed it should work as you described and we have code
in the installer to print a non admin warning. If this is not shown then it is a
bug.

On a related note: I have on my TODO list to enable "Single User" installation
in case a user tries to install Gpg4win without admin rights, because with the
modern gnupg versions we don't need admin rights anymore. Would this also have
solved your problem but or do you specifically want to have Gpg4win installed
systemwide?

Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.

Testing this I noticed that the curses fallback did not work at all for Qt5
versions of pinentry-qt even if display was unset. This i fixed with cd7b35e

But the DISPLAY=:noexist case is more complicated. The GTK pinentry does a
gtk_init_check which Qt does not have. I don't want to mess with X directly and
would have to look into this more how to do this then only when X is used etc.

There is a similar question on stackoverflow and I don't find any answers there
acceptable:
http://stackoverflow.com/questions/28525435/qt-equivalent-to-gtk-init-check

I've changed the topic to reflect that this is a feature currently not available
in pinentry-qt but I don't see it as a high priority issue.

Thank you very much. Straightforward fix. Applied the patch.

After testing on Windows this problem is not resolved for Windows (I agree that
it's resolved for posix).

The issue there that I see now is not that it's a race between changing the
setting and immediately reading it again but that sometimes the communication
between gpgme and gpgconf fails.

See attached file no-read.txt for some debugging on this. GPGME writes a changed
option to gpgconf but gpgconf does not read it. I've used OutputDebugString and
DbgView to have syncronized debug output over process borders.

Not 100% reproducible but on my test system it fails very often.