kwatchgnupg translation commited as revision 1641797 I leave this open as ticket for the rest ?

Thanks commited this to https://websvn.kde.org/trunk/l10n-support/ja/summit/messages/libkleo/ this should then be automatically arrive in the po/jp subfolder of libkleo. But I keep it as testing to check if this actually was done.

Can you therefore please clarify the purpose of the Libgcrypt LTS branch? My impression was that pairing the Libgcrypt LTS with GnuPG LTS was appropriate, based on both GnuPG and Libgcrypt LTS appearing on your downloads page at approximately the same time (from memory). Specifically, is there any issue using latest Libgcrypt 1.10.x with GnuPG LTS? Thank you.

See T6340 in case of build problems.

Will not be fixed because the only change is intentionally the export target for a regression test suite. The other fix is for the old FIPS RNG which is not used at all.

Thanks for the context Werner. This was missing from the commit which added the deprecation warning so all one could do is guess.

As I assume that many people have HTML emails still turned on, and have no crashes, there probably are more conditions that have to be met to trigger this crash.

Thought about this for a while and rephrased and thus repopened.
I think it would be good to remove or explain the sha1sum checksums in the announcements.
Whether they are replaced by something else, e.g. sha256sum is of lesser importance.

It turned out that this does not make much sense.

Kleopatra now runs the gpg/gpgsm processes one after another if multiple files are imported. (In fact, since we always try to import with gpg and gpgsm, this actually already happens when a single file is imported.)

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

Here is my fix:

Here is my change for libkleo Japanese Translation:

The attached patch removes the --supervised option from the example dirmng and gpg-agent systemd unit files.

Shouldn't we remove the sha1sum then as well? Or add an explanation?

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.