As I anticipated here's screenshot I also saved.
P.S. Just in case you might wonder why I tried to execute 'man' not existing command is because I also incorrectly tried to run it 2 days ago when after I tested some GnuPG commands in a CMD window, and again same window self-closed with no error messages or any dump creation and again I'm sure at that time I didn't run 'mode con' before those GnuPG commands (I'm unsure which ones but they probably some were the same I also already reported here). Please also note that making 'Stato del dispositivo CON:' so big was unintended and very likely just an effect of cut & paste I did, so now I'll try to see if I can avoid that effect.

Hello again Werner,

As the bug I located is a simple fix, I think it can be also applied to 2.2.

Ok, but the problem is that by default CMD command windows do not use any Unicode set of characters, and their default font is 'Raster characters' and the typical display of characters inside these windows, at least for Italian people because this was the default since MS-DOS age, is to only consider using MS-DOS ASCII codepage 850, not Unicode.
And this is also why before showing the error message I ran the command mode.
Anyway because of the 2 characters getting displayed instead of single expected 'è' (whose character code is 0x82) I can also tell you that by using Charmap.exe again (just in case you may not know it allows display of any Unicode or Raster font characters and their hexadecimal codes) and so switching its default font from System (Unicode) to 8514oem (raster, corresponding to 8514oem.fon) I've been able to determine which should be the 2 wrong displayed characters hexadecimal codes : 'Ã' (0xC3), and '¨' (0xA8) but here obviously both characters cannot be represented correctly because this site is using 'Segoe UI' font, which is Unicode too.
So the only main way to check that I identified the correct characters will be if you (or someone else you know) with another Windows client run Charmap.exe switch font to 8514oem (raster) and check that displayed characters corresponding to 0xC3 and 0xA8 are the same that got displayed in the error message bitmap I provided (a part from probably being able to find where in Italian messages localization rather then in source code those 2 characters have been used incorrectly).
P.S. Because in a past similar bug about Italian localization I saw a comment from you about this kind of option, please just let me know in case you think I might possibly be able to help you to review involved 'GPG' Italian error message(s) for this bug.

Hello Werner,

Well, as I've said in the comment above, there doesn't seem to be any correction towarads --passphrase-fd not requiring --pinentry-mode loopback (still works withou)... and --no-default-keyring still gives the impression that it would be needed (while --no-keyring works as well).

Please don't, if you really feel like tha tis not resolved please re-open this ticket.

That pretty much looks like the other errors you have with Unicode characters - which we can't replicate.

This is all build from the same source. We could fix that but I'll give that a lo priority. Thanks for reporting.

That's correct - The output needs to be percent escaped.

P.S. Also note that my Gpg4win 3.1.16 installation status is still last T5593 described one.

Here's the file I anticipated (this time uploading worked... :-D ) (my Gpg4win 3.1.16 installation status is still T5593 described one).

@werner shall I open a new ticket for the remaining stuff?

@bernhard thank you for explaining, did not mean to offend anybody. Before creating win-gpg-agent I tried to read as much as I could on a history and obviously had to study source a bit. Be it as it may - I decided to have separate wrapper, rather then contributing directly to gpg code base. There is noticable number of use cases on Windows which presently not addressed, some I believe are sitting it the queue already.

@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!

Since Windows user naively could expect multiple methods of accessing certificates from different programs (or sometimes from the same program but different supported environments, like Git4Win and git in WSL) to work together transparently, win-gpg-agent covers translation of one accidentally supported method (32 bit putty shared memory) to multiple unsupported ones (named pipe, cygwin, etc). It also takes care of managing gpg-agent.exe lifetime tying it to user login session for convenience. It uses command line parameters to only to overwrite staff critical to its functionality and does not prevent user from having configuration file(s). Optionally it provides pinentry which is integrated with Windows native Crypto Vault and UX rather than using wonderful QT or GTK. As specified in documentation when developers of gpg and WIndows will get their act together and figure out what they want and how they want it - most of functionality would not be needed. I would like to point out that simply claiming superiority and not supporting cygwin (Git4Win) or working Assuan ssh socket or putty shared memory in 64 bits Windows build does not help with user experience a single bit.

Thanks. This fixes the invalid packet errors when using --list-packets or when trying to decrypt the file without secret key.

Just to be sure. please provide the output of

Bug in creating such a blob is fixed in rG08a3a4db27dc: kbx: A 20 byte fingerprint is right filled in version 2 blob..

Lots of detailed documentation but frankly, after a brief read I have not yet figured out what it really does. We won't support Cygwin stuff - this is all obsolete and awe also removed starting gpg-agent as a service for good reasons. Instead of starting gpg-agent with lot of command line args it would be better to put this into a per user or system wide config file.

Works if one puts

rootdir = $APPDIR/usr

in the gpgconf.ctl file.

There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11

Fixed in rGcc6152b802f2: gpg: Skip the packet when not used for AEAD., but I put wrong bug-id in the commit message.

I was wrong to fix this issue; It is specifically the issue of PKT_ENCRYPTED_AEAD packet. And we already have code to skip the data part by free_encrypted. The problem is that free_encrypted is *not* called when it was PKT_ENCRYPTED_AEAD.

These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

Could anyone please be so kind to confirm me if when 'gpg4win-3.1.16.exe' setup completes without any error the new folders where Gpg4win and GnuPG commands can be found are prepended (so inserted at beginning) or appended (so added at the end) of already existing %PATH%) ?
I'm asking this to properly ensure that my new manually modified configuration %PATH% is indeed equivalent to an original configured one (and so far I've assumed that my manual changes should have been prepended %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% but doing this was probably only my choice because such changes were just faster to do).

@grv87, thanks for clarification (and very interesting side thread reference you gave, indeed, also because it also gives you an idea of how system environment changes during OS startup). I precisely see your point and that's also why I said "create 2 new system variables".
I've not said this very explicitly before but for that I also meant to just create them during Gpg4win setup. When it is run, I assume we can also say that OS system environment is already in place and %PATH% should already be stable enough to consider that as a good starting point to add things. So once you can really do that (I mean add 2 new system variables), and then also ensure they're created correctly, then I can also assume that then starting to use them to update %PATH% system variable might be fine too.

@swimmerm, my 2nd comment offers some solutions for you and other users coming here with the same problem with their PATH. It should be done on user side. I don't offer to implement this in Gpg4Win installer.

@grv87 OK, many thanks indeed for confirming all this.
About your 1st comment: that's just right why I asked about it. Regarding md5sum and pinentry both must be the reason why now they decided to also add 1st path into environment while in older version wasn't there. Main issue is that because of the quite generic 'PATH env variable too big' error so far we can only assume 2047 was indeed maximum size for %PATH% Gpg4win developers have been expecting so far, while after that change from March 2012 QFE fix a definitive fix to implement in setup and rest of Gpg4win involved code will just be to enhance that maximum allowed path size to 4095 characters (BTW also checking anyway for size of %PATH% already active before setup will continue with new %PATH% changes is probably best option too).
About your 2nd & 3rd comments: thanks for those useful references. Would probably be quicker to implement, but it's still again true that maximum size expected for %PATH% will still need to increment from (likely) 2047 to 4095, plus also what you said about something "for expert users only". And even then inside README.txt (that now corresponds to %ProgramFiles(x86)%\GnuPG\README.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.en.txt or %ProgramFiles(x86)%\Gpg4win\share\gpg4win\README.it.txt) there should be at least 1 note about suggested way to do things. Problem is that because of above (March 2012) MS KB article statements '... If an existing value contains more than 2047 characters, you cannot enter additional data. However, you can delete the characters that are displayed. ...' whenever %PATH% size is over that value (always true for me even after manual %PATH% downsizing I had to do) OS UI will be of no or very little help (and by very little I intend that to overcome that OS UI limitation expert users with Admin privileges will 1st need to manually modify Path value into Registry, let's say by adding at least 1 or 2 ";" really unneeded, then just use OS UI to modify %PATH% system variable by deleting those ";" unneeded (i.e. %ProgramFiles(x86)%\Gpg4win\bin;;%ProgramFiles(x86)%\GnuPG\bin;;) and then once removed confirm with OK twice, and voilà it's done).
(P.S. BTW I just checked that so it really works fine for all applications started after that change ;-D so this might probably be best known option to document inside that README.txt.
N.B. JFYI in the past I also tried to use SETX from command line, and so I discovered that it only has a 1024 maximum characters limit after which it will just truncate any expected change that is saved anyway into selected system variable).
Otherwise, another possible approach variation but unsure if needing more coding would be to create 2 new system variables (let's say Gpg4win and GnuPG) and then add both %Gpg4win%;%GnuPG%; in front of existing %PATH% while installing, but obviously still after enhancing maximum allowed PATH size to 4095.

On the issue, I think there are several possible solutions, better than current:

1. Warn user that PATH is too big and tell him which dirs should be added manually
2. Warn user that PATH is too big but still modify it. He has to modify it with something else than UI, so it's for expert users only
3. Ask user to choose between 1 or 2

BTW, there are known solutions to manage with PATH overgrowth.

@swimmerm, look at the files installed in both dirs.
There is no gpg in %ProgramFiles(x86)%\Gpg4win\bin, it is in %ProgramFiles(x86)%\GnuPG\bin.
On the other side, md5sum and pinentry are in the first one.
So, I believe you (and I) should add both dirs to the path.

Thanks. This looks good to me.

It parses wrongly. I think that we need a fix like:

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 1ee5b9a6e..7f51b263b 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -725,6 +725,9 @@ proc_encrypted (CTX c, PACKET *pkt)

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

That looks all pretty standard. I don't know what's going on. I need to be able to replicate it here.

Hello Mr. Koch,

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Somehow this looks like a bug in gettext or our usage of it. It seems as if the last characters of strings appended to translated texts are sometimes doubled as if the string was built twice, once with 1 or 2 more characters and then overwritten with a slightly shorter string. Very strange.

Sorry, I am not abale to replicate this with standard version of gpg. Hwoever, the portable version only changes the directories and nothing at the output code paths. THus I really wonder what's going on here. Note that the spaces used to indent the "mittels ..." are also missing.

Key verification: Double Number in the end of fingerprint:
The same problem, as with the portable version.

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see: