For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

okidok - understand and thank you.

Quite possibe and thanks for the report. However, this is a dev state of the things and thus not expected to work. I'll keep this open as a reminder for me, but in general I would prefer to get a report at the gnupg-devel ML.

Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.

Well this seems to be a gcc 4.2 bug. But well, forward declarations should go into a separate file so that tehre is only one place which would require changes. In this case it does not matter.

Hello again Werner,

Thank you for reporting.
Fixed in master.

Hi @Lambd0x, with Thunderbird having migrated to a different main OpenPGP implementation and Enigmail not supporting old thunderbirds version anymore (in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird) and new GnuPG versions over the last three years. Do you still have problems?

@werner I think @Rombobeorn suggests something like

Sorry, I can't read all your comments about this. The percent escaping is correct and required. If you want to use the output in a script you can get it without percent escaping by using for example

Hello again Werner,

OK, effect avoided. Only dued to a big sequence of '-' characters that this bug reporting system interpreted as special control code characters for making font bigger.

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.

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.

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?

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

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.

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.

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)

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,

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.

Sorry about that, I forgot to add GCC. I updated the original post with the needed information.

The keyserver network has been shutdown a couple of months ago. We can't do anything about it. The default in newer gpg versions has changed; you may put

Since the migration to a new machine with lots of config changes this spring the redirect rules for bugs.gnupg.org were not properly adjusted and when running into an error, it seems that the admin back then ignored the problem and simply removed bugs.gnupg.org from dehydrated's list of domains. Thanks again for reporting. Should now work again.

Sorry for your troubles but we need to protect against spam - a tracker flooded with spam is useless.

Sorry, I don't know which software has version 12.0.0 and which git master this is. In case this is stock libksba, please tell us at least the last commit id. Note that we in general do not support arbitrary versions from the repos but only released versions .

While I'm still waiting for anyone to possibly answer my last 'Sat, Sep 18, 6:29 PM' question I've also added there the explanation behind that question... :-)

Thank you.

Please see T5587

Tsss, requires to allow JS for Google.

LTO warnings are trashing LTO optimised binaries and that is definitelly gnupg code issiues.
Just check each two places where rowtines are defined and declared in header files.

Just FYI, see also how GnuTLS has proposed to implement the service indicator:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1465

GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

1. >>gpg2 --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6

Which gpg version?
Which Python library? (gnupg is pretty generic)
How does the Python library call gpg?
Are you aware that gpg uses utf8 and not Windows Unicode?