Nope - too long for checking and introduces line wraps. Those who are not able to check digital signatures are also not able to properly handle checksum verification. On some platforms you don't even have a sha256sum tool. And they need to verify the mails first anyway. Note that for internal purposes we use sha256sum for years.

Reported by https://social.tchncs.de/@duxsco@digitalcourage.social/109546865597565084

In T6328#166678, @aheinecke wrote:

@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.

For now that we do not want to push for more WKS support with gpgcom, as this will depend on adoption of WKS. So I am resolving this issue.

Since the issue T6328 described an issue with high pirority which would be fixed by this issue I am raising the prio here.

@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.

We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.

My understanding is that: selftest in Kleo does call assuan_socket_connect (possibly in kleopatra/src/libkleopatraclient/core/command.cpp), and it didn't send nonce correctly.

@justus: Please talk to @kuwv on how to transfer the package to him.

Thanks! I don't understand why your fix helps as Kleopatra never calls assuan_socket_connect on the server side, but it helps. :) So this is probably called indirectly and I don't see it.

We can simply change the arg type from number to string and use a value like 3072/20240101

Yes this is windows. With the USB Stick I think it makes it more reproducable that bytesToWrite will return something. We also had reports that this happened on Network drives so its probably just "some added delay or something where the Windows Kernel does not do buffering".

The first thing I noticed is that ProcessStdInOutput uses redirect_close<QProcess> as process class. redirect_close overrides QProcess::close, but it never calls the original close(). That's very dubious. Maybe it's not a problem, but there's no comment explaining why the original close() doesn't need to be called. Or maybe that's what is causing the hang in waitForFinished.

I found an issue in the assuan code of client side. This might be the cause of the server failure for nonce.

The followup of this issue for libassuan is: https://dev.gnupg.org/T6324

Hello Andre Heinecke,

I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.

So the problem is occuring when the output is finalized (which happens after the GpgME Decrypt Result is signalled). And when there are still bytes to write in line 332 https://dev.gnupg.org/source/kleo/browse/master/src/utils/output.cpp$332

What I mean is that our socket emulation is encapsulated in libgcrypt and details should not be visible to the caller. Further libassuan and kleopatra might be build against different libc versions and thus the used structures might also differ.

As you might have seen from the commits mkportable has been removed from Gpg4win.

From the NEWS assuan_sock_set_sockaddr_un was only added in 2014, years after the UIServer code was really last modified.

I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.

The question is why Kleopatra does not use assuan_sock_set_sockaddr_un as we do in GnuPG. See for example
https://dev.gnupg.org/source/gnupg/browse/master/kbx/keyboxd.c$1124 - was this a workaround back when we had no support for Unicode? assuan_sock_set_sockaddr_un and assuan_sock_get_nonce work together and their internal workings should be opaque to the caller.

Btw. This is how Kleopatra creates the socket: https://dev.gnupg.org/source/kleo/browse/master/src/uiserver/uiserver_win.cpp$34 which does not use a function that would set is_socket=1. My naive fix would be:

My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".

o.O have overlooked this since October.

This is most likely caused by an incompatible addon. See: https://wiki.gnupg.org/GpgOL/IncompatibleAddons

If no keyserver is configured GnuPG uses its default keyserver. "disable-dirmngr" would be the option to completely disable keyserver access but that is rarely used.

I think the current way is a good compromise. Turning this into a fatal error has also resulted in very many support cases.

On Windows, a whitespace character followed by a number in parenthesis at the end of the file name is now stripped from the proposed output file name.