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

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.