You are right. I originally left it open because it was in a different language but the first report. But it's cleaner to close it as a duplicate, also.
Sep 24 2018
T4129 is also a duplicate.
Thanks for the report. This was already reported andf fixed. We are aiming for a new Gpg4win / GpgOL Bugfix release soon to address this and other regressions.
Jul 17 2018
Jun 26 2018
Good news! :)
Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)
Jun 18 2018
I'm closing this as a duplicate of T3459
I'm closing this as duplicate of T3459
Jun 1 2018
Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.
Apr 27 2018
Mar 7 2018
Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.
Mar 2 2018
Sadly this is a known problem, the workaround is to unselect the mail and then move / modify it through the right click menu.
Nov 29 2017
Many thanks! This bug is fixed in Gpg4win 3.0.1.
Nov 28 2017
Thanks for the efforts. I will subscribe there to be up to date :-)
Oops I just noticed that this was already reported in T3424 which I somehow overlooked. Let's handle it there as there are more subscribers in that report and it's older.
Nov 27 2017
To keep the tracker clean I'm closing this as a duplicate of T3476 since both problems are very much related. GpgEx would print Internal Error if Kleopatra crashes or behaves unexpectedly.
I'm closing this as a duplicate of T3459 even if this bug is older we used it to discuss side topics.
Nov 24 2017
thanks for your report. We already have this on our todo with high priority: T3514
I'm resolving this report as a duplicate.
Oct 17 2017
Then this is a duplicate of T3442 as well! Thank you for you Logfiles and your report!
Oct 16 2017
Duplicate of T3441.
Apr 4 2017
I am sorry, Kai. I am afraid I can't close this bug.
Mar 30 2017
Mar 24 2017
Mar 21 2017
I close this one. An implementation is already in master.
Duplicate of T2819
Mar 15 2017
Yup! Fix works. Thanks, Justus.
Fixed in a98459d3f4ec3d196fb0adb0e90dadf40abc8c81.
Thanks for helping us diagnose this issue. Finally I understood the problem and
was able to reproduce it. Please keep filing bugs :)
I just pushed c7833eca38fdb8d9ba7b59438ea87d651b8bf7ba that will help us
diagnose the problem. Would you be so kind to apply it and rebuild your package?
You're welcome. By the way, you may be interested in this PR since you are
obviously a stakeholder in the matter:
Please feel free to comment/suggest/etc. if you have any thoughts!
Hi, I have been assigned to this bug, and we'll get to the bottom of this.
The plan is to patch the tests to dump the location of tools it thinks it should
use. I'd like you to run the tests with that patch then.
Thanks for working with us on these issues. It is really appreciated.
Any other suggestions?
Mar 13 2017
Mar 9 2017
Mar 2 2017
Thanks. Can you please run the test again with
make check BIN_PREFIX=/usr/local/Cellar/gnupg21/2.1.19
macOS 10.10, 10.11, 10.12
They're nearly the same, but T2980 has the workaround for this issue in
place (running make install first), so that it's clear the ssh-import.scm
problem is an independent issue.
Feb 12 2017
So i'm left a little confused here about what the resolution is. neal added
documentation, but ueno suggested it was wrong and contributed a patch for it.
However, that patch hasn't been applied.
Some additional questions about pinentry-emacs and INSIDE_EMACS that came up in
discussion over on https://bugs.debian.org/854797:
What's the best way to debug a problem when emacs pinentry isn't working? do we look at gpg? gpg-agent? pinentry? emacs itself? all of those places? What happens when the user has two separate instances of emacs running? What if there's an instance of emacs running and someone uses tramp to connect to a remote ssh server, and gpg-agent is providing the ssh-agent interface? What if someone uses ssh from *outside* of emacs and it talks to a gpg-agent that was auto-launched from within an emacs session? What about when there's an instance of emacs running in a graphical session on a machine where the same user is also logged into the machine via ssh, and they're using a different graphical session? how does pinentry-emacs interact with emacs --daemon and multiple emacsclient instances?
Another few questions:
Why does emacs use /tmp/emacs$UID for the ephemeral socket instead of
If OPTION allow-pinentry-emacs is set, but the emacs process isn't
repsonsive (or nothing is listening at all) should pinentry do a second layer of
fallback, e.g. to curses?
Dec 29 2016
Duplicate of T1828
Please comment on T1828 (I just granted you permissions)
Dec 2 2016
Duplicate of T2859
Oct 31 2016
That's awesome aheinecke! Honestly wasn't sure if this issue would ever get much
attention. Thanks for the effort in making Gpg4win a more secure product!
Oct 28 2016
Duplicate of T2341
Thanks for your report,
This was already fixed in T2341
Which is currently not yet released. I'm marking this issue here as released
with superseder (duplicate) to keep the tracker clean.
GpgOL is built with DEP and and ASLR now. Need to enable this for GpgEX and some
other parts of Gpg4win, too. So not yet fully resolved but I keep it in mind.
Sep 28 2016
Duplicate of T2359
We track this now under T2359
Duplicate of T2359
Aug 5 2016
Jul 19 2016
Yes, that is very likely the same bug. Feel free to reopen this report if yuo
can still reproduce it, in which case a backtrace would be very handy.
Fixed in 28fd0ab.
Jul 14 2016
Jul 5 2016
Thanks for your report. With gpg4win-2.3.2 we addressed that problem. See also
issue2319 which was also about this problem.
Please let us know if you still have that problem with 2.3.2 I could reproduce
it in testing and with the fix it no longer happens so I'm hopeful this can be
Duplicate of T2319
Jun 9 2016
Sorry for going AWOL on this, Werner. Do you still need a backtrace from me, or is the
one from 2371 enough?
It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.
In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
Jun 8 2016
So, how do we proceed? Release 2.1.13 and wait for potential problems?