I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the problem was sending and no receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6

Hello,
I'm having the same issue here, and as I've an image in the signature of my emails the signature is not visible at all when I sign the messages.
The image attached seems to be well included in the attachments and the image is readable.
Thanks,
isundil

I think it's worth noting that this is not restricted to encrypted e-mails but signed-only e-mails also.

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.

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?

Thank you werner for the quick reply!

• Werner Koch via BTS <gnupg@bugs.g10code.com> [20170317 12:57]:

Fixed with commit 69c521d.
You can reconfigure your server. Thanks.

4ce4f2f683a17be3ddb93729f3f25014a97934ad allows make check to complete without
the other workaround. So it works as advertised! Thanks, Niibe and Justus.

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
posteo.de.

Most other sites work.

The patch has been applied to master and the 1.7 branch. A 1.7.6 will be
released soon.

• Original Message ------

From: "Andre Heinecke via BTS" <gnupg@bugs.g10code.com>
To: aheinecke@intevation.de; dr_it@mailbox.org
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.

Thanks again,
Andre

Applied with commit 0a90f87799 to master. I will backport and release 1.7.5 today.

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?

Fixed in 4db9a425644dccaf81b51ebc97b32a9cc21941a4.
Test for --export-ssh-key added in 47b8b9e2ce5af7fba117ae0b00e10bec414dcfb0.

I've just announced a new 3.0 beta that contains the updated GpgOL

http://lists.wald.intevation.org/pipermail/gpg4win-devel/2016-November/001659.html

Please let me know if it still crashes for you with that version.

OK, I don't care enough to warrant more discussion/work on this.
"Unknown elliptic curve" is already better than "Invalid elliptic curve".

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

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

A little bit better, but that would still confuse me, as I did not intentionally
specify an elliptic curve.
What could help here is:

1. talking about algo/algorithm (that is shown in the man page as parameter for

--quick-gen-key)

2. saying which algorithm gpg saw.

If the error message had been "Unkown algo 'user@example.com'" I would
immediately know that I provided an email address where an algorithm was expected.

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.

1.4 has been released - waiting for 2.0

Done with commit d25db3c for 2.1.15