Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.

I tested encrypt two txt files with filename 1 and 2.txt and insert text: test 1 and test 2. Tararchive has been created successfull. Than i tested this Two txt files with a long name. See attached txt files, i send it already to you. Now by the first test Archive.tar.gpg.yqoirl with 0 Bytes was created.
Second test, the other archive.tar.gpg with 0 Bytes was created and gpgex hang.

What you uploaded are files with a length of zero bytes. That is not valid data. The hang should not happen of course.

In https://wald.intevation.org/forum/forum.php?thread_id=2395&forum_id=21&group_id=11 "Kim Nilsson on 2022-02-15 16:48" reports that

Hi,
(Exec format error), read 0 bytes

Did you make another request for locating keys via WKD after adding the debug flags? I'm asking because when I do this I get the following log:

2022-02-10 17:49:59 dirmngr[6780] listening on socket '/run/user/1000/gnupg/d.f3hdqcrmjwf98p87yqjmuctx/S.dirmngr'
2022-02-10 17:49:59 dirmngr[6781.0] permanently loaded certificates: 130
2022-02-10 17:49:59 dirmngr[6781.0]     runtime cached certificates: 0
2022-02-10 17:49:59 dirmngr[6781.0]            trusted certificates: 130 (130,0,0,0)
2022-02-10 17:49:59 dirmngr[6781.0] failed to open cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt': No such file or directory
2022-02-10 17:49:59 dirmngr[6781.0] creating directory '/tmp/tmp.8P2EakNghu/crls.d'
2022-02-10 17:49:59 dirmngr[6781.0] new cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt' created
2022-02-10 17:49:59 dirmngr[6781.6] handler for fd 6 started
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Home: /tmp/tmp.8P2EakNghu
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Config: /tmp/tmp.8P2EakNghu/dirmngr.conf
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK Dirmngr 2.3.5-beta17 at your service
2022-02-10 17:49:59 dirmngr[6781.6] connection from process 6779 (1000:100)
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- GETINFO version
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> D 2.3.5-beta17
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- WKD_GET -- werner.koch@gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: libdns initialized
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(openpgpkey.gnupg.com): No name
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: getsrv(_openpgpkey._tcp.gnupg.com) -> 0 records
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> S SOURCE https://gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] number of system provided CAs: 390
2022-02-10 17:49:59 dirmngr[6781.6] DBG: Using TLS library: GNUTLS 3.7.3
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:connect_server: trying name='gnupg.com' port=443
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(gnupg.com): Success
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:1917:socket_new: object 0x00007f524c290e20 for fd 7 created
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> GET /.well-known/openpgpkey/hu/waoubdep9643akkesx4xm3ynstfffiok?l=werner.koch HTTP/1.0\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> Host: gnupg.com\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request-header:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> \r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:response:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> HTTP/1.0 200 OK\r\n
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Date: Thu, 10 Feb 2022 16:49:59 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Server: Boa/0.94.14rc21'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Accept-Ranges: bytes'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Connection: close'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Length: 957'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Last-Modified: Mon, 28 Jun 2021 17:47:11 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Type: text/plain'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: ''
2022-02-10 17:50:00 dirmngr[6781.6] DBG: (957 bytes sent via D lines not shown)
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 <- BYE
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK closing connection
2022-02-10 17:50:00 dirmngr[6781.6] handler for fd 6 terminated

Add the following to dirmngr.conf:

debug ipc,dns,network,lookup

There are more debug flags but the above flags should cover anything related to the lookup.

You may have to restart the dirmngr to see the log-file option be honored. The gpg request to dirmngr should be visible in the log.

In T5813#154705, @bernhard wrote:

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

In T5813#154552, @Valodim wrote:

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

After further testing: The error does not occur if WKD is implemented directly under the respective domain.
The behavior of GnuPG differs between Windows and other platforms. However, it is not clear to me which version is behaving incorrectly. But it seems clear that there is no compatibility with the instructions at https://keys.openpgp.org/about/usage#wkd-as-a-service under Windows. (However this may concern another project.)

The server in the testcase is wkd.keys.openpgp.org which is referred with CNAME via the DNS. Referring to https://www.ssllabs.com/ssltest/analyze.html?d=wkd.keys.openpgp.org it shoud support TLS 1.2

Check that the server does not prohibit TLS 1.2 - a few server admins allow only TLS 1.3 for whatever security threats they have in mind.

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::