This works, there is only one gpgsm process at a time while importing a dozen S/MIME certificates at once.

yes, one down, two to go...

signing works, too

follow up of T6517

works (I did only check the first 2 criteria)

I have built it according to the method described here.
(https://wiki.documentfoundation.org/Development/BuildingOnWindows)

Meanwhile the AppImage (same binaries as the current Gpg4win version) can be found here among the binary releases: https://gnupg.org/download/index.html

I can't find a missing forward port; need to debug this issue with gpg4win 4.2.0

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"

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