This issue is not concrete enough to have some kind of "done" so ->invalid

This issue is invalid.

Thanks, Werner.
With the latest data everything works fine.
I also a problem with incorrect cipher state resetting if last chunk is 0-size.

C:\Users\XavierFRUTON>gpg --gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

The only other add-in that I use is Skype, but I`ve disabled that and re-uploaded the log. We are using Exchange 2010 SP3

Thanks. Error is there:

Thanks, file attached

I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.

That is weird, I've never heard of that before.

rW981a6fae5355 Fixes the problem with Kleopatra's config files.

That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.

I did some digging with Wireshark:

1. there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
2. DNS reply returns correct IP address in A record
3. there are no outgoing connections to proxy IP address

The button shows and I can select Sign or Encrypt but they don't register / stay selected they just have a grey highlighted background whilst hovering over them... they do not toggle / stay selected.

Is it possible that your %APPDATA% directory is redirected? Maybe you are running into T3818 I also got "General Error" when trying to generate a key because of that bug.

What do you mean by "Does nothing"? The button should toggle and then when you send the mail kleopatra should show a dialog to select the signing / encryption keys.

With the attached commit gpgconf works. Key generation in Kleopatra also handles the case now that gpgconf does not work.

The underlying problem is that gpgconf does not work in such an environment.

Note that "Wrong name" severely misses information about that it is connection related in any way. :)
Just adding "Connection problem: TLS: " would already help a lot.

Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.

Debugging network problems is always hard and applications should not include tcpdump facilities. Right, I consider TLS network failures identical to layer 3 network failures because we should assume that all traffic is encrypted. Wrong certificates are also a severe network failure much like wrong voltage levels at layer one ;-).

I found another encoding error which renders the test data uploaded yesterday useless: Here is a bogus AEAD packet:

00000040  d4 84 01 07 01 00 6c 34  7c 37 83 24 2a 11 bc 1c  
00000050  bd 1a 76 da 93 8a
              [start chunk] 32 cd  80 a5 8e db 3a 7d 4a 40  
00000060  c5 0d 82 01 8d 64 7f 65  cd ca 58 d0 e7 db 3b 5e  
00000070  89 d9 1b c8 d9 93 1a 37  3c 0e a5 8f 4b 0d 9f db  
00000080  34 56 c8 f1 e9 b7 f5 0b  d2 53 4f 6c fd f8 e9 16  
00000090  cd a4 ae f6 7f 65
                      [tag] ef 5f  96 af 62 70 f4 30 27 37  
000000a0  68 61 95 0a fb 23
                [extra tag] a6 66  75 7a 47 bb 57 d3 da 5a  
000000b0  4d d1 c2 2f 43 39
                [final tag] cd 22  91 16 1d 92 17 1f f2 cf  
000000c0  0f c9 11 56 d0 a9

Just to clarify:
1.I'm behind corporate network
2.Network resolves only local addresses, so this is correct: dirmngr[7416]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
3.Network address of the proxy is resolvable (I can see it's address and it responds to ping
4.Internet browser without proxy will not work
5,Internet browser with the proxy below works
6.When using gpg on this computer outside of corporate network everything works

The stripped down log is

@werner Problem persists (same results with disabling ipv4 or ipv6

Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py

password is "abc". I have some comments in the commit logs.

Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.

Hi Werner, thanks.
Looks like our tests against GnuPG are passing now.
Can you please provide the password for this file as well? 'password' doesn't seem to fit.

@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru

Here is a file

same behavior on gpg 2.2.1

Could you please try on the command line. (If you don't know how, see: https://www.wikihow.com/Open-the-Command-Prompt-in-Windows )

The problem is still that other - non-gpgme threads - can still use getenv and friends without us noticing that. But I see no solution for this. In any case this code is the best we can do.

Hi aheinecke,
I did some tests with 2.0.7-beta10 and still found some issues.
The message I attached as a test case in previous comment is now properly handled, I see no "signature.asc" attachment and message is correctly tagged as trusted sender; this test message was sent from Evolution and I sent it to myself (sorry for not pointing this out before).

My test works now with this commit.

I think the problem is with the selction change event. When we query for selection item (1) we trigger an itemLoad event which apparently causes this behavior. I've disabled everything else in our event handling code so we don't touch the mail at all (non crypto mails we never touch much).