@aheinecke: Please change the Original URL to https://dev.gnupg.org/w/gpg4win-or-gnupg-vs-desktop-bug-report/
. This creates a cover sheet which does not ask the user to login or register an account to later just realize that she may seatch the tracker w/o an account.
Wed, Dec 1
Tue, Nov 30
Sat, Nov 27
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).
Mon, Nov 15
Oct 25 2021
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::
Oct 20 2021
Okay. So the product prefix has been added intentionally to the version.
This commit changed the behaviour:
When changing the filel contents of C:\Program Files (x86)\Gpg4win\VERSION from
the update check works again.
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.
Oct 19 2021
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
gpgconf --query-swdb gpg4win 3.1.15
i.e. with the current version. Here, on Linux, I get
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
Oct 18 2021
I would prefer to store legacy manuals on the web server. That is the easier solution.
@werner, because we have talked about it:
Oct 14 2021
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.
Oct 13 2021
Oct 12 2021
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.