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.

I*m sorry, but I haven't found a way to determine what version of gnupg I am running. Just in case things got confused, I am not the thread opener, my version of gnupg is not whats been stated in the opening post but rather whatever is current on Arch Linux: Linux 6.0.11-arch1-1
I ran gpgsm --version though which returns this:
gpgsm (GnuPG) 2.2.40

Please update to a recent gnupg versions. 2.3.3 or if you really need the LTS version use 2.2.40. Instead of using a log you can import on the command line:

After years of using S/MIME I ran into a strange situation importing my new S/MIME certs to Kleopatra yesterday which ultimately led me to this thread.
My case is slightly different because my original passwords were short (2w7g9r1e and 2y8m7i5t), but it feels related so I thought I'd share nevertheless.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

I've hit that issu on downloading two times so I think that there are two nodes behind LB :P

Just checked those two commits and I see in autoconf output:

checking for gpg-error-config... no
checking for gpgrt-config... /usr/bin/gpgrt-config
configure: Use gpgrt-config with /usr/lib64 as gpg-error-config
checking for GPG Error - version >= 1.36... yes (1.46-unknown)
configure: Use gpgrt-config as libassuan-config
checking for LIBASSUAN - version >= 2.4.2... yes (2.5.5-unknown)
checking LIBASSUAN API version... okay

So looks like there is more use of *-config scripts and those detections takes longer time so it would be good to move that as well to pkgconfig.

External projects should have been using pkgconfig since a long time. The *-config scripts are for systems which lack pkgconfig.

I cannot find the commit which fixes this issue.

Thank you for your report.
Please look T6204.
Closed as duplicate.