Hmm, two years old - I doubt that it makes sense to continue here.

i am not the original owner of this bug, but facing the same issue.

Assuming 4.1.0 means gpg4win - this version is too old. The user should update and re-open the bug with more details if it persists.

Lot's of changes since 2.4.

The code has meanwhile been reworked and the mentioned test server is not anymore available

Added --enable-maintainer-mode to ./configure

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

Please try using the current version (3.1.14) and if the problem persists re-open this bug. In this case we will also need a more detailed report.

No more info was provided.

No info received in3 years.

The current version is 0.9.10 and the reported 0.9.5 is 4 years old. We also received no more info.

That's fine. The 2.0 branch will reach EOL in 6 months and we will
probably only do a last maintenance release. No need to backport this
fix, though.

Btw, if you want to use the test script, you have to use "gpg2 --keyid-format short".

I have verified that it works fine in 2.1.21. I did not test 2.0.30, but that's very old, just use the latest 2.1.x version. gpg 1.4 also only receives critical fixes.

I don't know if this ever landed. If not, please reopen. We now have a bug tracker that can do nice patch management, too :)

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.

I see. We use system() in the random test to re-execute itself. This involves
the shell and thus the problem. Need to uses fork/exec or CreateProcess calls
for that test. I guess this needs to wait until we have moved that to code to
libgpg-error as our portability layer.

This is still a problem on OS X 10.11.5. OS X's System Integrity Protection
"feature" is causing that test failure. If S.I.P is disabled there's no problem.

A similar-looking test failure happens in perl
(https://rt.perl.org/Public/Bug/Display.html?id=126706). Perhaps the diagnosis is
the same here.

Feel free to -re-opne if you experience the same problem with a current gnupg
version.

Libgcrypt 1.6 will be released this year.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

Let's assume that the problem was in the glib library and has been fixed in the
meantime. I will soon release a new Gpg4win version with the latest stable glib
version. Feel free to reopen if you still encounter this problem.

2.0.5 is too old. Feel free to reopne if thatt problems is still in 2.0.19 or
later.

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

Is this bug solved? And if yes, in what version is resolved?