Applied the changes for libassuan T6487 into gniibe/t6606.

Merged to master (to be 3.0.0).

Pushed the change in gniibe/t6606 branch.

@jukivili Good to know.

My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.

BTW. The icon is breeze "view-sidetree" which I found fitting to split a larger opaque MIME structure (e.g. an encrypted mail) into different parts.

I have added an observer repository for mimetreeparser here. So you can now use the keywords like "GnuPG-Bug-Id:" and your commits will be visible here on the platform. We can later switch the "upstream" URL to something else of course. https://dev.gnupg.org/source/mimetreeparser/

in our study we've found that personal users often did not know that their software is capable of sending encrypted email. I blieve that most of them want a protected communication by default. (I may have seen surveys about this at some time as well.) If the recipient has published their public key, they are indicating that they can receive encrypted email.

I am not really a fan of this. I can respect this as a wish but it is currently not my vision. What you are really asking is basically that we lead the private users into sending encrypted mails without knowing that they are doing it. This will lead to frustrated users who then blame KMail for their bad user experience.

Linked from https://wiki.gnupg.org/EMailClients/KMail

Saving an attached messaged (in mbox format) is something that I sometimes want. It should be okay to implement.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t

Fixed in: rP66abf7cb1e1b: Update GPL2 for new FSF address. Use URL for license.

works, tested with the provided example certs

information shows now up immediately, when the public key data is imported

On Windows with gpg4win 4.2.0 the filenames are suggested as in the description of this ticket, that is "Archive.tar (1).gpg".
But this is no issue, it can be decrypted with Kleopatra without any problem, anyway. The name of the decrypted folder is "Archiv.tar (1)" but it is a plain folder, no tar archive.

Fix pushed to the 23/07 branch and master.

On 64-bit Windows, the situation now is:

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.

Here is a test program for 64-bit Windows to see how cast works:

#include <stdint.h>
#include <stdio.h>