Unsure whether to bump this or report it as a fresh bug, but the testing-scdaemon-inside-a-sandbox-on-macos issue has returned in GnuPG 2.1.21.

I have not looked at this since I did some work on the pinentries, but if noone fixed this then yes, it is still an issue. Indeed, I just quickly read over the source:

Justus, is still still an issue?

Fixed in 2.1.21.

Fixed in 2.1.21.

Automatic creation of socket directories creates cleanup trouble for projects previously relying on the agent-shutdown if $GNUPGHOME is removed: https://notmuchmail.org/pipermail/notmuch/2017/024550.html

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.

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.

Patch applied and pushed to STABLE-BRANCH-1-4.

Those scripts are likely already broken if their input happens to be different than what they expect, so i don't much care about "breaking" them. That said, it sounds like you're suggesting that the default mode will just be "--decrypt" and we'll let people continue using it that way.

This seems to work just fine on our archlinux box with the nsswitch configuration above.

I looked around a bit and found many places where the decryption was given as the default operation for gpg and thus requiring -d would break a lot of tutorial. Of course we could educate the user in attended mode that "-d" is now required but I fear that this will break too many scripts.

In T2844#96255, @marcus wrote:

phabricator already mirrors these repositories, and the mirrors are accessible via https, e.g. https://dev.gnupg.org/source/gnupg.git
How about just pointing to these and leave git.gnupg.org git-only?

Justus, will you please so kind and take care of this.

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.

The debug log includes communication between host PC and the reader, thus, it may include your input of PIN when you do that.

Ping? Otherwise I would provide the required information.

Sorry, I was wrong. The patch also works for signing to key.
The impact is gpg frontend always asks gpg-agent for card key.
It involves invoking scdaemon and accessing to USB.

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.

For signing (not sign to key), here is my attempt:

Can we activate this for --import and --recv-key as guilhem requested?

I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org

phabricator already mirrors these repositories, and the mirrors are accessible via https, e.g. https://dev.gnupg.org/source/gnupg.git
How about just pointing to these and leave git.gnupg.org git-only?

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.

I can't seem to reproduce the above or my original issue. I just upgraded to a newer Ubuntu release where gpg2 is now the default instead of gpg. Maybe that's what fixed it.

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.

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.