Commited with revision 1642622.

I am closing this now, as we now should have complete kleopatra translation and can just move one of them to testing.

I am pretty sure that this was related to issues we found when analyzing another crash / hang with Kleopatra. In T5478 we are currently reworking how we handle archives completely. This will fix this issue, too.

Thanks a lot.

Commited this state with revision 1642162

Not yet fully finished, but it's better for me to put it now:

I leave this open as ticket for the rest ?

I'm that user - only thing I can think of really is that I used the tool "O&O ShutUp10++" to restrict Win10 Settings. During the troubleshooting I reverted to the standard settings, but it made not difference.

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.

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.

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

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

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

Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

This is probably not the right place, but considering you're telling people *here* that they should not build in the source tree, your README and INSTALL files do tell the users to do exactly that.

Your response to my other bug report (T6320) advised me not to build in tree and that fixed the "make check" problem. In turn, that means I no longer need to patch Makefile.am and run autoreconf. That has made this Development Version warning to go away.

See T6310 and the release note update at T6303.

Sorry, I can't replicate this.

This bug is CVE-2022-47629

Pushed the change.

Ah, I had not done git pull for a week, and I didn't realize your patch.

I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.

I will push this change:

commit e89d57a2cb10bd04d266165015f159be2ab48984
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Dec 21 10:52:24 2022 +0900

You should do it for all software ;-).

Has been remedied. We should have noticed before the release but the heavy warnings you get only appear if the binary is downloaded from the internet.

This was an accident. Will be fixed ASAP.

Sorry, one more thing: I should use out of source builds for all gnupg software (libgpg-error, libksba, etc)? It's fine if so, just want to check what the policy is.

Ah, thanks! I didn't know this was unsupported. I'll change what we're doing.

You are building in the source tree - not a good idea. This should be supported but we don't test this. Please make your life easier and don't do build this way. We try to fix this for the next release.

@raysatiro: Please re-open if you are able to give us a reproducer

Fixed. Shall we backport this to gnupg22 ?

Thank you for your reply! I'll modify my testcase

I figured out the situation.

Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.

Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.

Thanks. Commited to master.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

works

Fixed by reverting to 2.5.5

Problem is that Kleopatra uses the latest libassuan from Git and not the released version. Replacing the libassuan DLL with the one from the gnupg directory fixes the bug.

Missed some, will post an updated patch.

The debug output is

[2560] org.kde.pim.kleopatra: Checking Ui Server connectivity...
[2560] UI server not running, starting it
[2560] org.kde.pim.kleopatra: UiServer: client connect on fd  1528
[2560] org.kde.pim.kleopatra: UiServer: nonce check failed
[2560] org.kde.pim.libkleopatraclientcore: Could not find  "kleopatra"  in PATH.

which means that libkleopatraclientcore couldn't start kleopatra, but at the same time the UiServer seems to be running? Okay, maybe the lines are in wrong order and the connect doesn't fail because the server isn't running but because of the wrong nonce.

The actual problem at hand is that the nonce is not correct. The UI-Server is actually started but if a client (or the self-test) connects the connection succeeded but then the server needs to check the nonce which does not match. Procmon shows that there is only one nonce writen - so the problem might be that the server has different copies of the nonce.