The bug with the long filenames has been fixed but it is not yet released. Release will be in gpg4win 4.0.1 See T5754.

vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.

These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.

Potential fix posted here: https://invent.kde.org/pim/kleopatra/-/merge_requests/11

In T5783#153879, @werner wrote:

Sending a private key with just the local protection is not a good idea.

In T5784#153872, @werner wrote:

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

That seems to (mostly) work partially fix PowerShell pipeline output at least:

Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin

We use GetConsoleOutputCP but fallback to GetACP if the former fails. For some reasons one of the functions seems to return 437.

That is annoying enough that we should do a new release. I close this bug, though.

See T5758: scd: loop forever with reader_port, when open_pcsc_reader failed. Yes, the workaround is not to set reader-port.

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64

See T5758. The workaround is not to set a reader-port.

Downgraded the gnupg to 2.2.33 using this installer and I am now able to successfully open the Kleopatra GUI.

Should also note that once the GUI is opened, GnuPG's smartcard deamon (32 bit) transitions to Very high power usage and appears stuck there, consuming a full logical core's worth of CPU time.

Unfortunately same story for GpgOL v42.5.1. Tried disabling all non-Microsoft plugins, however to no avail. Signed and encrypted messages are shown as blank, whereas I can see the content of the signed e-mails in the Outlook web client and on my iOS device.

The debug log was from gpg and not from dirmngr and thus it is not helpful. I also guess that an older dirmngr was still running, because the LE bug has been fixed in 2.3.4.

In T5744#153233, @alexnadtoka wrote:

And --keyserver-options check-cert is removed from new gpg versions (((

Here is log in english

And --keyserver-options check-cert is removed from new gpg versions (((

@werner can you show me tutorial for proper bug submit? I think it is a bug and gpg client on Windows does not support valid LetsEncrypt certificates on keyserver. It does not work with any keys server . Tested few public keyservers as well. ((

Please see https://gnupg.org

@werner Thank you for the answer. Please advise mailing list address.

For support please use the mailing list and not the bug tracker.

GNUpg version 2.3.4 was installed but did not help

Is there a way to ignore SSL check during connection? This might work. We have internal server for our users only.

I get

Access Denied: Restricted Application

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

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.