Thank you werner for the quick reply!

Good catch. Only on Windows64 sizeof(int)==sizeof(long) and thus the generic definition does not work.
Fixed in master and 1.7: rC7a339b1fc94cbda738cf7712830e783faa0e325e

Hi werner, I have just managed to find a solution and its really weird.
I have seen that on this platform, the mpi-asm-defs.h is being linked from the generic folder and not from the AMD64 folder. All other asm files are nicely linked fro the AMD64 folder. Here is the relevant part from the build log:

Sorry, I can't access the build output (probably JS riddled paged). Please attach the config.log here.
In case you are building _on_ Windows: We do not support this - it may or may not work. All builds need to be done using a cross compiler from a Unix system.

Dirmngr uses its own resolver for these reasons:

debian stretch's 2.1.18 also suffers from this (debian bug tracker). As there is only 13 days left for fixing issues in stretch, swift action is needed.

Indeed.
However I am more concerned about the directory traversal, which seems be unintended and unnecessarily dangerous.

Let me quote from the man page:

@gniibe , I'm not setting the max-passphrase-option. Currently, my gpg-agent.conf looks like this:

@landro , Do you have any key which might require passphrase update for its expiration?
I mean, do you have an gpg-agent option of "max_passphrase_days" set (default is not set).

(Since I was writing by phone, the sentence was terse. Sorry. This time, by PC.)

What do you mean by connection error, @gniibe? I hope the user is not impacted by what you are suggesting.

For smartcard, yes. The feature for ssh with smartcard has been available more than ten years. I recently apply the approach to gpg frontend.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

@werner, can you please quickly outline how you imagine this to be fixed? Our jabber discussion is gone from my memory, and my client does not keep logs for MUCs for some reason.

Just noticed one more thing - I'm not trying to use a smartcard at this time (I plan on moving to yubikeys in future though) - why is "new connection to SCdaemon established" all over the logs?

So I'm using pinentry-mac in my gpg-agent.conf:

So I noticed your log contains lot's of "starting a new PIN Entry", I assume you are using some kind of password manager integration, so that you don't need to enter it each time (sorry, I'm not familiar with how pinentry works on macOS).

Ok. To reproduce, I believe the key is to establish lots of connections (in my rig around 20) to (possibly different) ssh server(s) (possibly by going through a bastion) within a short timeframe.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

Too bad. I installed both libgcrypt and gnupg using homebrew, and apparently there is no way to make homebrew include debug info. I guess I could build from source and include debug info - where can I find instructions on doing that?

Hm, it did not give us the location in the source unfortunately, only
the offset from the top of the function, which the original stack trace
already contains. Maybe the library does not contain debug information.
Depending on how you installed that software, there may be a way to
install the debug symbols too. That would make bug reports much more
helpful. Thanks anyway, maybe the log will help us trace the problem.

https://build.opensuse.org/package/live_build_log/openSUSE:Leap:42.3:Staging:A:DVD/gpgme/standard/x86_64 looks good. Closing this task.

The test framework changed considerably, and the reporter is not responding with details. I don't believe this is applicable anymore. I'm closing this task. Feel free to reopen with more information.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

In https://dev.gnupg.org/T3027#97654, @justus wrote:
> Hi @landro, thanks for the stack trace.  Could you please try to resolve this frame
>
>   4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

Here it is. @justus

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2
openpgp_s2k (in libgcrypt.20.dylib) + 594

@landro Thanks a lot. I think that we see some failures in the log, and there might be another bug in the failure path.

In T3027#97654, @justus wrote:

Hi @landro, thanks for the stack trace. Could you please try to resolve this frame

4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

to a source code location? I believe it can be done this way:

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2

I tried to reproduce this issue locally but failed.

Here is the output of the log file

We can close this. The current Master of GpgOL states that Outlook 2003 and 2007 Support is no longer maintained and we will remove support for this altogether in new versions. With current Master this issue also no longer occurs.

Fixed in npth 1.4.

Fixed in npth 1.4.

Fixed in npth 1.4.

I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

In the crash log of 2017-05-22, I can't find any race or violation of shared object. It looks like some malloc related error.
Does gpg-agent emit error message(s)?

Hi @landro, thanks for the stack trace. Could you please try to resolve this frame

Just retested this with 2.1.21 - unfortunately gpg-agent is still crashing. Se new attached crash log.

Sorry, my fix was not good. Re-opening.

Can confirm here too. Applying that on top of 2.1.21 works perfectly.

Yes that fixes it!

I put another bug in 2.1.21. Please try: rGa8dd96826f84: g10: Suppress error for card availability check.

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.