Accidentally mixed up the ticket number. The correct commits for this ticket are:

Oops. I confused the ticket numbers rO34f6bb73882e: Implement send again for crypto mails. Would be the correct commit for this ticket.

Right, outlook.com is often problematic, although it might be a generic Exchange 2016 problem. Outlook.com and Exchange 2016 behave much the same.

For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.

You are right about the fact that multiple steps could result in unusable cards in case of power down before all commands have been issued. Nevertheless, in practice, these commands would involve very few treatments on the token (i.e. no cryptographic operation or heavy data transfer) and it should really not take long to complete the three steps (admin PIN update, user PIN update, KDF-DO update).

You are right in that enigmail uses no-auto-check-trustdb

As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.

man dirmngr

I'm not sure about that (Bug in Evolution), because I see ist only in E-Mails send by Evolution via Mircosoft (outlook.com) and not if Mails werden send by Evolution via Google (gmail.com).

In T3751#110422, @cipherpunks wrote:

What's in daily use for 15 yrs? GPGME? I thought GPGME was new,

Since the initial redacted data for those four keys is still accessible, I checked all of those keys manually and none of them are on the keyservers. Since the OP was connecting to the specified keyserver successfully prior to that failure, I believe this is the cause of the error and not another DNS vs. Dirmngr conflict.

This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.

A work-around is now available for this in Python in the GPGME source. The relative path from the top of the GPGME source directory is here lang/python/examples/howto/groups.py. Like all the other scripts in the same directory, it also appears in the GPGME Python Bindings HOWTO, under the Miscellaneous heading near the end.

Workaround is implemented in 2.2.6.

Fixed in 2.2.6.

My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.

I've got an example mail. The problem is that the mail itself is "Content-Type: multipart/mixed; boundary="_003_DB4PR08MB01092D175DE8C1861B5D0BC197BF0DB4PR08MB0109eurp_"
"

dunno how to attach a patch here... trying to copy it verbatim

reproducer

--debug-wait 3

@werner here's the only output I get:

Please kill all existing dirmngr instances and don't run any programs which will trigger it to be started (e.g. Kleopatra). Then run in a _standard_ shell (cmd.exe):

I, too, have this problem. I have Windows 10 Pro 64-bit with BitDefender Total Security. My first reaction when this wasn't working was to disable all functions on BitDefender. That didn't help, so I ran dirmngr as admin in cmd (I despise PowerShell) without any luck. I created a non-admin user and ran it in there, again without luck. I've come up dry. No logs, no output, and no answers. Is there anything shy of downgrading dirmngr that will make this work? Has there been any progress as to figuring this out?

I'll go for a warning / error for now and see if I can fix the renumbering.

Rhat's for the client, right. I never used it. We used to run a Windows 8 instance in a VM to run tests via ssh on it. That worked most not really stable. For obvious reasons I am more interested in the server part ;-)

Thanks. I took these patches and simplified them. Not test tested, though,.

Note:
When we change the allocation, hmac256.c will not be standalone any more (as commented in the head of the file), and we will need to change the compile-command line to include libgpg-error.

I check this report again.
The test is single thread, IIUC.

I would argue that the Windows port of OpenSSH is not unstable at this point, especially given that Microsoft is even providing it as an installable feature in the next regular Windows 10 release. The fact that the port is now using actual OpenSSH version numbers instead of their own 0.x versions lends credence to this as well.

Thanks for the fix! however, the fix only addresses the two flags we currently know about. I've pushed a branch T3880-fix that tries to implement the If the agent does not support the requested flags […] It must reply with a SSH_AGENT_FAILURE message part of the spec.

It is in 2.2.6

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

Yes. However, I have tested a fix for the empty value.

Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.

In fact, renumbering of attachments happens also by just viewing them repeatedly. This likely causes multiple copies somewhere, reducing disk space.

Have you tried it multiple times? If it's unintialized memory access maybe you got lucky?

I still can't reproduce the crash (on Vista).