The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

thanks for help - could have been my mistake as well, so better look twice.

Sorry. I looked at path_add and not at path_remove, see my garbled line numbers I started at 1062 and not 1162.

A few people asked for this generic option help; it is not specific to keyservers. Now we implemented that and still not okay for everyone, oh dear.

Marcus: That would be a good opportunity to get back to your old curses works ;-)
IIRC, we fixed similar bugs in the past but this is for the latest pinentry.

gpg: Note: '--keyserver' is not considered an option

Marcus, can you please check this?

Option parsing stops at the first non-option. "--keyserver" and "sec1...." could have also been key specifications.
Because sometimes people make errors we print a warning. But we can't bail out on a perfectly valid command line. That is the same why

I don't see the bug. Please elaborate. path_new is is freed in line 1065 but if this condition does not match it's freed in line 1079.

Indeed, the difference seems to be the --output versus the stdout to a file.

The difference is the use of the --output option versus redirecting stdout to a file. A first guess would be that setmode (O_BINARY) has not been done, but in that case the -a exports would still work.

This bug was introduced when I tried to handle T1983: gpg2 prefers missing secret key to available key on card. In master, this bug was fixed in: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.

I released libgcrypt 1.7.7
and nPth 1.6

I just released 1.7.7

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.

@aheinecke thanks! My apologies for not making that clear in the initial report.

*facepalm* Ooops. I see. Thanks for the report. I'll fix it.

werner, a quick question: what is the ETA of the new realease? I'm asking to see whether should I apply a temporary patch for the Windows64 build, or rather wait for the new release?

@aheinecke Yes, the issue is with INTERFACE_LINK_LIBRARIES not IMPORTED_LOCATION.

Uhm I thought this was fixed with 2e661b9e1a9b50656a5c9646d7444a98477010c1 that should have been part of GPGME-1.9.0 are you sure that you are not seeing this with an older version?

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.

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.