works just fine, thx!

With the changes in 3.1.0 I think this is acceptable enough that we can move further improvements to this to a lower priority.
We only support PGP/Inline (no-mime), warn if an attachment is also added. A user could send attachments encrypted on a file basis.

All subtasks are in testing.

I've opened T3895 for a permanent decryption / permanent removal of attachments. Maybe something for 3.2.0 ;-)

So I used a debugger to see if I could garner any additional info. Here's the log:

When an attachment of a crypto mail is removed it now leads to a warning.

In my tests it does work nicely now. We detect the "Send Again" state and correctly handle it. Sign / Encrypt is preselected depending on the state of the original mail. Even works with attachments.

Never seen the crash again.

New version of GnuPG is now packaged.

Argh. I missed that. Probably because I searched for libgpg-error but I myself renamed the tag recently :-(.

Put the check in configure.

To clarify: We already use the getrandom system call if it is available. To map /dev/random to /dev/urandom you can create a file /etc/gcrypt/random.conf with this line:

The following post assumes that we want gpg --search to try to search; meaning that we don't want gpg to exit immediately because of the dead marks, without having sent a single network request to anyone.
The post is a bit long; sorry about that.

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.