I'm seeing something quite similar - same setup, osx and it only shows when using ansible. I'm on gnupg 2.2.3, also saw same using "GPG Suite 2017.2".

This patch was released with 1.4.22

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

A new installer is now available:

GnuPG 2.1.22 in Homebrew is out: https://github.com/Homebrew/homebrew-core/commit/39a392ffd6ac20a36ea8a4aec5c4dc5febcfc1d6
Please check it out.

Also a lot of redirects, for example this bounces you from https to http.

FWIW, using a Debian specific thing is not portable and Unix sockets won't work on Windows. Thus using the standard localhost connection is simpler than adding extra complexity.

Okay, I implemented the second part and Tor is now used if availabale.
--no-use-tor disables Tor.
--use-tor forces use Tor and can't be reset.

Should be resolved. Reopen if it is still an issue.

@marcus sure, but I am currently away on vacation and won't be back until mid August. Also, I'd need some detailed build instructions (I'm on mac os) since I'm not very familiar with building C code - I brew installed gpg.

It is fine to close this. Reworking the parser is not going to happen anytime soon.

Because werner says he fixed the memory access, I am closing here. werner, if you want to keep track of the invalid encoding issue with the asn.1 parser, please open a new task with some details. pascal, if you find anything missing, please open new tickets (as you said, it's easier to keep track of issues in separate tickets).

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

@landro Would you like to do one more round of testing?

We have to check what happens here, because list-sigs should be fast.

In T1938#99890, @marcus wrote:

It's unclear from the discussion if this issue has been resolved.

It's unclear from the discussion if this issue has been resolved. @werner can you please comment on this?

No I don't recall any such problems, sorry.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

Still an issue in gpg 2.1.21.

I'm going to close this task now. If we need more options to be configurable, it is easy to open another task for them.

Libgcrypt 1.6 reaches EOL in 7 days, so we won't fix it.

I released libgcrypt 1.7.7
and nPth 1.6

libgcrypt secmem fix is not that in hurry, I think. nPTh bug for macOS sounds more severe.

So, should we do a new libgcrypt release RSN?
There is another bug with solution also pending and it might not be too late for Squeeze if we hurry.

I managed to replicate this issue by preparing artificial nPth on x86 GNU/Linux.

I fixed a bug in nPth: rPTH4fae99976c31: Fix busy_wait_for.
During this debug, I also found a bug and fixed in libassuan: rA62f3123d3877: Use gpgrt_free to release memory allocated by gpgrt_asprintf.
Also, I fixed two related bug in GnuPG:
rGc03e0eb01dc4: agent: Fix error from do_encryption.
rG996544626ea4: agent: Fix memory leaks.

@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:

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.

"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

Fixed in npth 1.4.

Fixed in npth 1.4.

Fixed in npth 1.4.

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.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

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

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

Applied to master (formatting the commit log), and pushed.

Thanks for your confirmation. I pushed the commit.

Pushed: rG116cfd60779f: g10: invalidate the fd cache for keyring.

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).

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.

By the commit: rGf053f99ed0b0: scd: Handle unexpected suspend/resume by CCID driver., I put some code to handle such an expected return from the device.
Please try.
I couldn't reproduce this on my machine. (Suspend-to-RAM keeps my USB device running.)

Applied as ebe12be034f0.

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.

It works for me on NetBSD 7.1. Please test.

Fix published in 2.1.20.