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.
Jan 5 2021
Aug 9 2020
No more info was provided.
Jul 16 2020
No info received in3 years.
Oct 15 2018
The current version is 0.9.10 and the reported 0.9.5 is 4 years old. We also received no more info.
Jul 1 2017
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
Jun 30 2017
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.
Jun 23 2017
Jun 22 2017
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 :)
May 23 2017
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.
Mar 30 2017
Feb 3 2017
Jan 6 2017
Jul 14 2016
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.
Mar 29 2016
Mar 17 2016
Jan 26 2016
Jan 22 2016
Jan 15 2016
Feel free to -re-opne if you experience the same problem with a current gnupg
Nov 12 2015
Oct 28 2015
Aug 11 2015
Jun 16 2015
May 11 2015
Dec 11 2014
Sep 17 2014
Jun 23 2014
Dec 10 2013
Libgcrypt 1.6 will be released this year.
Aug 12 2013
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
Aug 9 2013
Jul 30 2013
Jul 1 2013
May 22 2013
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.
May 1 2013
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.
Apr 19 2013
2.0.5 is too old. Feel free to reopne if thatt problems is still in 2.0.19 or
Aug 14 2012
Aug 8 2012
Jul 20 2012
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?
Is this bug solved? And if yes, in what version is resolved?
Jul 13 2012
Mar 26 2012
Please re-open if you still see this problem.