This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

This would be a good solution.

This has also the advantage that we could list the possible curves and let the user select them.

So should we revert this patch and replace it by an explicit command to switch the card to ECC?

Ben, can you please use a more descriptive subject for the commits. One of the reasons is that our jabber bot at gnupg-devel at conference dot jabber.gnupg.org shows just the subject and that is not really informative.

It looks like you're having the same issue that I reported: T3761.

Hey, @uwestoehr. It looks like you're having the same issue that I reported: T3761.

There was a second person asking for a list-packets feature to verify if a file is encrypted correctly at gnupg-devel.

Ok, thanks!

Sadly this is a known problem, the workaround is to unselect the mail and then move / modify it through the right click menu.

Hi Andre

I'm not a fan of memoryhole. To say my criticism in one sentence: "Memoryhole is trying to sell the hide of the boar before it has been hunted."

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