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.

I can repropduce this with gpg (GnuPG) 2.1.17 on Chakra Linux.

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?

I confirmed that mingw-w64 version 1.0 defines timespec.
So, for older versions of mingw-w64, we need a fix to avoid errors.
But, your suggestion of __MINGW32__ != 1 seems wrong to me (I think it is always defined as 1).

Sorry, merging/closing is not good. This should be a subtask of T2291.

We need to change how to access scdaemon from gpg frontend. Thus, I merge this to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)), setting its priority to High. Please continue at T2291.

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:

Yes, 2.1.20 has the issue, too.
The crash report can be explained as: if the double-free can occur when multiple threads access to the cache at the same time, allocation in md_open may crash.

I finally got around to test this again - sorry for the long wait. I testet with 2.1.20 - same behaviour as in 2.1.19. Crash report attached.

Could the priority of this bug be pushed up? I was trying to follow the instructions to verify a Centos 7 install image, but was unable to view the fingerprint using the version of gpg I have installed on this system - gpg (GnuPG) 2.1.19. This feels like a very bad regression from a UX perspective.

I've updated to gpgme-1.8.0 and tried again.
I have one mail that I'll call "bad" which gives me in mutt:

Please use GnuPG 2 (2.0 or 2.1) for using smartcard/token.
smartcard support in GnuPG 1.4 is way old and only supports shorter key length.

This bug is not reproducible for me. I don't think it is Yubikey specific.
I suspect some failure for the transition from 2.0 to 2.1.
In GnuPG 2.1 the private keys are stored under the directory gnupg/private-keys-v1.d.
Do you have this directory?
How does it goes when you prepare another directory and specify that?
I mean:

mkdir SOME-NEW-DIRECTORY
gpg --homedir=SOME-NEW-DIRECTORY --card-status

This is fixed in bf8b5e9042b3d86d419b2ac1987a9298c9d21500.

Applied as ebe12be034f0.

I confirmed that it's 64-bit big-endian.
I wrote a patch for testing. D421: padding is needed for 64-bit big endian

If s390x is big-endian, we need padding at the start of the cell structure. So that the _flag can be compatible to the vector element.
I'll see on the porterbox myself, too.

I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.

Fwiw b83903f59ec5d49ac579f263da70ebc8dc3645b5.

@gniibe good catch! I'll fix that and we'll see if that improves things.

IIUC, cells are used for a place for vector elements.
I'm afraid what happens for memory space not used for vector elements.

resolved with 94645311f8a3e9ae33643512f87fbef41bf0556f

Please just keep discussing *one* issue per task.

It was run automatically. Installing libbz2-dev did not help.
Output stays the same.

Steps to (hopefully) reproduce
Cloned the developtment branch and reverified the commit hash described in
https://www.gnupg.org/download/git.html
[Removing https://git.gnupg.org/gnupg.git would be great, since cloning that did not work]
$ ./autogen.sh
$ ./configure --sysconfdir=/etc --enable-maintainer-mode && make
$ make check &> check.log
make does not exist also, though cpu seems to not work on

You need the development package installed (e.g. libbz2-dev on Debian-like systems). Then, rerun configure and rebuild.

$ gpg2 --with-colons --list-config compressname
cfg:compressname:nicht komprimiert;ZIP;ZLIB

Adressed in 94645311f8a3e9ae33643512f87fbef41bf0556f.

The 4gb-packet test reads an OpenPGP message compressed with BZIP2. If that test fails, it most certainly means that you compiled GnuPG without support for BZIP2. You can check this with:

'82' is the line of the failing assertion.

fwiw, this remains a problem on 2.1.20: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=s390x&ver=2.1.20-1&stamp=1491409561&raw=0

While I can't reproduce this problem myself, I think I found an issue of gpg-agent passphrase caching.
Double free may happen when multiple threads enter agent_put_cache, for example.

Err... npth repo is not yet added under dev.gnupg.org.
I requested as T3064.

Thank you. I just tried:

autoreconf -fiv && ./configure && make && make check
...
Making check in src
Making check in tests
make  check-TESTS
PASS: t-mutex
PASS: t-thread
PASS: t-fork
==================
All 3 tests passed
==================

on NetBSD-7.99.67/amd64.

git://git.gnupg.org/npth.git

Thanks for working on this.
I can't seem to find a link to the repository for testing, can you please point me in the right direction?

I found that FreeBSD also requires -lpthread thing. I also commit the change to the repo.
Tested with FreeBSD 11.0.
I think that TrueOS can be considered as FreeBSD variant.

Fixed in the repo for DragonFlyBSD 4.8 too.

In T2998, NetBSD was fixed.
I'll check for DragonFlyBSD.
IIUC, FreeBSD and OpenBSD has no issue.

It works for me on NetBSD 7.1. Please test.

I tested with NetBSD 7.1 and -lrt is not required.
Nevertheless, it would be required for older NetBSD, so I leave -lrt check for NetBSD.
I'm going to push the change of D415 now.