According to my checkout this is at

werner@trithemius.gnupg.org:/cvs/gph

But that has long gone. I need to see where to find a backup of that repo.

No way to test on El Capitain anymore. It works on Sierra.

We now have a GPGME feature to list packets:

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

With the new rndjent as used with libgcrypt 1.8 under Windows rhis can be claimed as finished.

Solution has been given: Use "gpg.conf-1" for gpg 1.4

I have tested this and it appears to fix the leak of gpg-agent processes in virt-builder, thanks.

I commited a change which should fix this on Linux

Thanks for testing.

Well, this is a regression due to us creating creating /run/user/gnupg/ socket directories now on the fly. Thus there is no more need to create non-default home directories via gpgconf. Now, gpg-agent watches the socket file and terminates itself as soon as the socket file vanishes. Before that change the socket for a non-default home directory was created in the homedir itself and thus removing the homedir also removed the socket file and in turn gpg-agent terminated itself.

Confirmed that it now compiles ok on Fedora, thanks.

Thanks for the reminder. Fixed.
Note that LIBASSUAN_LIBS is not needed because it is already part of t_common_ldadd.

This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.

For anyone following this bug, someone has worked out a (very awkward) workaround: https://stackoverflow.com/a/27689596/2505159

I'm still hitting this on Fedora. The patch is simple and was posted on the mailing list but apparently not incorporated into git:

No response anymore, and we can not reproduce.

Assigning to Werner for "re 1."

@werner Can we close this here?

@werner I can't find the gnu privacy handbook sources, although they are mentioned here: https://gnupg.org/documentation/guides.html

Thanks for the fast response!

we don't use GPG4Win anymore ... so, honestly I don't know - if you want I can verify that. Or you simply close the topic ...

We don't use roundup anymore.

Is this still an issue?

Is this still an issue with the latest version?

Is this still an issue?

I don't think we can do anything about slow startup times due to anti-virus software, sorry.

Is this still an issue?

According to Wikipedia, Live Meeting was discontinued. https://en.wikipedia.org/wiki/Microsoft_Office_Live_Meeting

Is this still an issue?

Is this still an issue?

It's not possible, unless you convince the Emacs developers to add special support for it. See http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00798.html.

I used this workaround for the years I accessed my mail over ssh and emacsclient.

In many cases, it's possible to make two connections (e.g. via ssh) to such a server, and in one of those connections explicitly do:

Justus, thank you for the response and your time. My apologies if I raised an issue in vain.

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