By the way, when terminating pinentry with "kill -TERM ...", it shuts down correctly, while CTRL-C show "gpg: signal Interrupt caught ... exiting" and a corrupt screen layout that is reset when pressing RETURN, further confirming the above diagnosis.

The problem seems to be that the CTRL-C is sent to gpg, terminating it, but pinentry keeps running and interfers with the terminal. With "ps -j" we can verify that pinentry runs in the process group and session of gpg-agent, while gpg runs in its own process group within the shell session. So, the signal rightly goes to gpg.

Fixed in 48aae8167dcae80d43b08167a88d9eb170781a04.

Fixed in badc1cdae52bd434e5fac2e4275575afeccc2837.

Agreed, that is odd.

Yes, the passphrase is cached by gpg-agent.

I'm not sure I understand the problem. Importing that key seems to work just fine. Listing as well.

Fixed in 6e23416fe61d4130918f2d1bf6e1f98d102c4610.

I can't find the string ' Generating a basic OpenPGP key for our unit test' in the GnuPG 2.1 source nor in the the 2.0 source. Thus it seems to be a modified version of GnuPG. I guess that is the 2.0.30 you mentioned. Please run

What is your operating system?

here's a public key version of the same key. it was available easier and should reproduce the bug just as well

Refile if problems with current versions.

We can do this with estream now.

Fixed as of 9b12b45aa5e67d4d422bf75a3879df1d52dbe67f.

It doesn't seem to impact performance significantly:

In T3203#98567, @Valodim wrote:

The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)

user ids with length 0 do conform with rfc4880, though

I'd suggest to skip such user id. Actually I had in mind that we did that in the past - but I may be wrong.

Justus: When you have implemented that, can you please do a test with my key before and after? As you may know, I have hundreds of vanity signatures so that I need to have

The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)

Out of curiosity, how did you create the key? What is the use case?

This is fixed now. The fix 15d2a009931f44a60b9df6325f837add208459d6 should be easy to backport.

and the platform is ...

-----BEGIN PGP PRIVATE KEY BLOCK-----

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.