I think it's worth noting that this is not restricted to encrypted e-mails but signed-only e-mails also.
Jun 29 2022
May 24 2022
Dec 1 2017
The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".
Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS
Yeah, that looks correct. Good catch. The bug exhibits itself when gpg-agent checks its own socket. In this case gpg-agent is both, client and server, and due to our userland multi-threading we get blocked. The suspend/resume things makes the deadlock more likely. Note that we have the same problem on Unix.
Jun 1 2017
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?
May 30 2017
Thank you werner for the quick reply!
Mar 30 2017
Mar 28 2017
Mar 20 2017
- Werner Koch via BTS <firstname.lastname@example.org> [20170317 12:57]:
Fixed with commit 69c521d.
You can reconfigure your server. Thanks.
Mar 17 2017
Mar 13 2017
Mar 9 2017
4ce4f2f683a17be3ddb93729f3f25014a97934ad allows make check to complete without
the other workaround. So it works as advertised! Thanks, Niibe and Justus.
Mar 6 2017
Mar 1 2017
Feb 23 2017
ntbtls support is now available in master and we will release a TLS enabled
2.1.19 installer for Windows.
Right now it is somewhat limited and does not work with some sites, notably
those which allow only ECC ciphersuites. An example for such a site is
posteo.de. Note that posteo.net sends a a bogus certifcate with rediretion to
Most other sites work.
Feb 13 2017
Jan 31 2017
Jan 23 2017
Jan 18 2017
The patch has been applied to master and the 1.7 branch. A 1.7.6 will be
Jan 16 2017
- Original Message ------
From: "Andre Heinecke via BTS" <email@example.com>
To: firstname.lastname@example.org; email@example.com
Sent: 16-1-2017 15:35:25
Subject: [issue2892] GpgOL: Encrypt is selected on Reply/Forward
Oops wrong, 251 did not yet have it, 253 will have it. Forgot to push the change.
Ok, I found the problem, as we handle the selection changed event in the
messagelist we were trying to decrypt messages even if they were not loaded /
visible in the preview window. That caused a weird state and several errors.
I've fixed it now so that we only decrypt items when a selection changes in an
Explorer that has a visible preview pane. I'll let you know once a beta with
that fix is released.
Jan 13 2017
Jan 11 2017
Dec 22 2016
Dec 15 2016
Applied with commit 0a90f87799 to master. I will backport and release 1.7.5 today.
Dec 13 2016
I'm glad that git has this fixed. Well, then the actual problem is that it is
broken in release.
Even being gentoo user, I cannot install gnupg from git easily (there's no live
ebuild for gnupg yet). So users will suffer from this until you make next
release and distros maintainers update packages.
So regarding functional tests for shell utils... Any suggestion how to arrange
that? Or would you review whatever I come up with?
Nov 29 2016
Nov 28 2016
Nov 16 2016
I've just announced a new 3.0 beta that contains the updated GpgOL
Please let me know if it still crashes for you with that version.
Nov 15 2016
OK, I don't care enough to warrant more discussion/work on this.
"Unknown elliptic curve" is already better than "Invalid elliptic curve".
Nov 14 2016
The algorithm parser works by checking the known "classic" algorithm and then
assumes that anything else is an ellptic curve. You see that all over the place
where you can enter an algorithm name. Thus there is no way to change this.
1.25 has been released.
To be clear: I want the
- less specific and
- already existing
error message "Unknown algorithm" (instead of "Unknown elliptic curve", which is
not correct in too many situations)
The --quick-gen-key command with the additional option is for use by scripts and
they should be able to read the manual.
If you look at the code you should see why it is a lot of work for a bit more
specific error message - we already have way to many messages. I could easily
find dozens of other places where we - in theory - could primt more specific
error messages. That would turn into a neverending story.
The string "Unknown algorithm" already exists. Because it is less specific, it
does not indicate that there is a problem regarding support for elliptic curves
Nov 11 2016
Thanks a lot. I will test as soon as you release the test build.
gpgol 2.0 won't change the messages on the server anymore there might be code
paths leading to that under error conditions but i'm not aware of any. And the
fallback is first to try to revert them.
That is a bit complicated and would require new strings. I do not think that is
Nov 10 2016
A little bit better, but that would still confuse me, as I did not intentionally
specify an elliptic curve.
What could help here is:
- talking about algo/algorithm (that is shown in the man page as parameter for
- saying which algorithm gpg saw.
If the error message had been "Unkown algo 'firstname.lastname@example.org'" I would
immediately know that I provided an email address where an algorithm was expected.
Oct 28 2016
Sep 28 2016
It is now patched in gpg4win and I think aheinecke pushed the patch also to linux.
The Bug iteself has been resolved with that patch, but is yet unreleased.
Sep 22 2016
Sep 14 2016
Aug 22 2016
Aug 18 2016
1.4 has been released - waiting for 2.0
Done with commit d25db3c for 2.1.15
Aug 15 2016
Aug 12 2016
Jul 14 2016
Jul 13 2016
Patch applied with commit c52829e for 2.4.3.