Caveat, Caveat (Warning, Warning) I know I've been quite busy with other activities, and ITMT my client status went really bad and even worse reached its final point and self-rebooted while I was trying to suspend it, but anyway this update is needed because I just discovered that my last choice to prepend %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin;%PATH% was not very good. Why ? Simple, as I discovered today (few hours ago) using this syntax, will only be valid&useful only if you really want to restrict Gpg4win v3.1.16 usage only to accounts in Administrators group.
Ok, so now you're wondering: How I discovered this effect ? Again simple, desktop shortcut that I have for starting new 'Command Prompt' was modified to always run as Admin, so I have to specifically choose when I want to run it without Admin privileges, and so today, after I didn't notice I had launched Kleopatra before, right after closing it, I launched a new Command Prompt and so when I tried to run 'gpgconf --kill gpg-agent' I only received this answer :

'gpgconf' is not recognized as an internal or external command,
operable program or batch file.

So then I obviously opened another 'Command Prompt' as an Admin and correctly killed gpg-agent so ensuring that everything was indeed still working as expected.
So now you're asking, why in the past I had confirmed that prepending those paths I was expecting to work, really worked ?
If you remember well how I reported Iìve done my past installations and tests, I also made those changes in OS System Environment Variables really on the fly and then just re-confirmed they were valid via GUI by simply pressing [ OK ].
And so this is the test I just repeated again and so I can re-confirm you that only after by doing so, every new 'Command Prompt' started as non Admin user will have proper access to those newly prepended paths.
Otherwise, those paths will work only for any new 'Command Prompt' if run with an account in Administrators group.
So while this can still be temporarily fine for me, I'm unsure it might have been a real standard choice for Gpg4win v3.1.16 setup run without experiencing the error I'm reporting in this bug, so please just ensure to avoid using %ProgramFiles(x86)%\Gpg4win\bin;%ProgramFiles(x86)%\GnuPG\bin; syntax when changing your paths on the fly by prepending it or appending to %PATH% even if you should try to definitely solve same error I found and reported with this bug. OK ?
Thanks for your attention (for now).

The thing is that any n.m.k-something version should behave versionwise the same as n.m.k. That is okay, because beta versions etc are not considered to be released. This is required to allow testing beta version _before_ doing the release.

Thanks for creating the issue.

Kleopatra now also handles a version like Gpg4win-3.1.16-beta15, but gpgconf --query-swdb seems to ignore pre-release identifiers:

$ gpgconf --query-swdb gpg4win 3.1.15-beta16
gpg4win:3.1.15-beta16:u::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

Okay. So the product prefix has been added intentionally to the version.

This commit changed the behaviour:
https://invent.kde.org/pim/libkleo/-/commit/bf7af017d84747d83ec16e0f8ab03b656899bfcd#c50ded182b9e04dd8e8c34c84c3bfd32ec2c5b46_149_214

When changing the filel contents of C:\Program Files (x86)\Gpg4win\VERSION from

Gpg4win-3.1.15

to

3.1.15

the update check works again.

rW4dcba538b74e2ad2d64adb4273176a4e4f85e599 changes the contents of the VERSION file as part of T5056 both on 2020-09-20.

Well spotted @ikloecker !

Well, the debug output

org.kde.pim.kleopatra: No update for: "Gpg4win-3.1.15"

and, even more clearly,

GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 0] = C:\Program Files (x86)\GnuPG\bin\gpgconf.exe
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 1] = --query-swdb
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 2] = gpg4win
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 3] = Gpg4win-3.1.15

reveals that Kleopatra via gpgme ran the command

gpgconf --query-swdb gpg4win Gpg4win-3.1.15

i.e. that current is "Gpg4win-3.1.15".

@ikloecker Note you can easily setup a test instance using one of Microsoft'S test VMs, see https://lists.wald.intevation.org/pipermail/gpg4win-devel/2021-October/001769.html

We should disable the menu button until it is fixed. I think it should be on the roadmap of 4.0 to have this working.

Version check is a data leak anyway and thus often disabled. Thus I don't see a risk for high value targets.

Adding GPGME_DEBUG with 9 to the logs, there is not much more to see:

With the following settings done as described at
https://www.gpg4win.org/doc/en/gpg4win-compendium_29.html

Kleopatra runs

gpgconf --query-swdb gpg4win 3.1.15

i.e. with the current version. Here, on Linux, I get

gpg4win:3.1.15:u::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

as result. The u in field 2 indicates that an update is available. The (current) code should work as far as I could see by a quick glance.

@werner can you prioritize?

This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe

I would prefer to store legacy manuals on the web server. That is the easier solution.

@werner, because we have talked about it:

Even better. Thanks,

The information is shown on the primary tab of the About dialog. Displaying the information in the Libraries tab requires bleeding edge KDE frameworks because the possibility to show custom information on this tab has been added very recently.

A way to get the output of "gpgconf --show-versions" might also be useful. Actually this command could be used to get the versions.

Just adding this note because a next step I'm also evaluating in my current T5593 configuration status it to temporarily create a new Gpg4win 3.1.16 hybrid configuration by also adding latest GnuPG v2.2.31 to see if all issues I reported here are still present (which is also quite probable).
Also because of T5593 it would just be quite interesting to see if GnuPG v2.2.31 too might experience same T5593 path related error.

Hi Werner,

As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.

Sure they don't get created - they are optional.

In that case maybe GetUserDefaultUILanguage. Thank you for considering.

Thanks for the info.

Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

Thanks for the log, however, I would suggest to use 3.1.16 and try again.

Just tracking my own additional investigation still about past Werner statement "percent escaping is correct and required" when this bug was closed for 1st time.
Also found interesting past references into rG055f8854d3f4 and rGe064c75b08a5 but only this last seems indeed much more specifically directly involved since it really contains related part of code (common/stringhelp.c) directly involved with this bug report for 'percent escaping' ':' (colon) character with '%3a' string even if sometimes, when possibly un-needlingly done, may even provide users unexpected on-screen displayed results like those I documented in this bug.
Problem now is that to really fully understand why on-screen displayed strings by 'gpgconf --list-dirs' correctly show a ':' (colon) correctly expected character near an unexpected (by end users) '%3a' (percent escaped) string that should just have corresponded with another simple (& user correctly expected) ':' colon character I can only really see to 2 options:
A) reopening this bug once again :-S ;
B) simply opening a new separate one asking for some additional explanations and maybe even to consider some future slight code changes to (at least for Windows OSes) ensure 'gpgconf --list-dirs' directory displayed paths results are more UI consistent with 'gpgconf --list-dirs homedir' or 'gpgconf --list-dirs sysconfdir' displayed ones where displayed C:\... paths always correctly display ':' (colon) instead of '%3a'.
So far this last seems me best viable option also because in same rGe064c75b08a5 I also saw another piece of code (tools/gpgconf-comp.c) with some similar code lines, that apparently (it seems me) if directly referenced (at least only for Windows OSes only, so maybe when a system variable %OS%==Windows_NT exists) instead of current one (common/stringhelp.c) also providing '%3a' 'percent escaping' results, might then have probably also easily avoided '%3a' user unexpected on-screen displayed results only depending by 'percent escaping'.

Just adding this note for any future reference needs only (or even message localization reference, since involved text characters strings are also expected to be among Italian language localized messages even if involved strings are not specifically being localized).

Hello again Werner,

Enigmail's support for Thunderbird 68 ends in two days:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

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,

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,

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).

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).