@werner also I suggest to check the default setting for this, see https://www.list.org/mailman-install/customizing.html and you can use the scripts mentioned there to check the configuration of several mailinglists at once and change it, if you know, which one is to blame, e.g. the host_name value.

@werner
Can you take a look at the host_name setting at the [General Options] configuration page for the lists in question,
e.g. https://lists.gnupg.org/mailman/admin/gnupg-devel

I think this issue is not resolved completely:
Currently I can see the same behaviour as descrived in T5330 (https://dev.gnupg.org/T5350) in all current versions of Kleopatra.

Does the problem even occur if the secret key stubs have already been created?

I agree that this will be less important when T5836 is done. But on the other end, someone personalized a smartcard for you. Ideally when inserting the smartcard it will fetch the public key from LDAP but if that is not configured or available you will have the same case of a smartcard that creates the secret key stubs and then importing the public key. As I think that in the case of exactly one key imported a keylisting through the agent of this one key won't be that expensive we should fix this as a minor issue.

I think this is mostly an issue during the setup of smart cards because Kleopatra lacks the functionality to delete the locally stored secret key without deleting the public key. Therefore, currently, it is necessary to delete secret and public key and then to re-import the public key.

tested and this works.

Tested and this works.

This is now in

inflateGetHeader does not seem to be called by anything from KDE. The only hits are from a copy of zlib included in marble.
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=inflateGetHeader

Thanks for mentioning this. I looked at the CVE last Sunday and figured that we are not affected. The vulnerable function inflateGetHeader is not used by GnuPG because we don;'t support the gzip format.

The more relavant error is that there is no status output on failure which is what gpgme uses (due to double forking).

gpgv returns success iff the signature is valid. That is the whole purpose of this tool.

Please give a step-by-step description how to reproduce this.

I'm asked three times for the passphrase, but otherwise I can confirm this.

Possible root cause: The S/MIME details window seems to lack a parent.

I have introduced this hint exactly because it's impossible to describe the rules automatically.

These hints are taken from the help.txt file.

gpg-agent passes to pinentry a short and a long hint for the passphrase constraints (see constraints-hint-* in pinentry.texi). If these hints are set, then pinentry shows them even before the user has started to enter a passphrase. The error message can then simply be "Read the hint, stupid!". Just kidding, of course.

Can you please give a more detailed example with regedit files to demonstrate that?

Can't we get them from the help.txt file? Putting a tooltip into the pattern file would be an option but needs substantial changes,

Yeah, we known. Fix is rGf34b9147eb3070b see T6070

We could use single letters or icons (with proper tool tip and accessible name). I'm not sure mentioning the cert usage is that useful.

Another point where this is very problematic are S/MIME certificates for signing and encryption. While the certificate line edit and the certificate combo box filter the usage, Groups are problematic. If you want to create an encryption group and include one "signing only" certificate the whole group is no longer visible for example in Outlook when encrypting. Both me and Eva thought that S/MIME Groups did not work at all in Outlook because of this.

Thanks for testing. I guess I will do a new release.

Standard behaviour for stdio functions.

Applies cleanly and fixes the crash. 👍

For master (2.3) the fix is not needed due to another way the code works, but having a more robust function is always good.

You may try the above commit - if should apply cleanly to 2.2.37.

You are right. This due to your old binary private key (stubs). Otherwise you would at least have one item ("Key:"). I need to see what do do about the release. Maybe a tool to update the key files would we a good workaround.

Oh well, why do I receive such bug reports right after the next release :-(

Sorry for the confusion ...
There was no single gpgol-File for deletion.
There were 100.000 other files from other programs.
No idea, why this has interferred with gpgol, but it obviously has.

Ok. So I never assumed that you had actually 100 gpgol_enc_number.dat files lying around.

Should be OK for mingw.org's MinGW. I cannot test the MinGW64 bits, but I trust that you did.

I encountered this issue of struct stat when compiling for x86_64 of Windows.
I'm considering this patch:

diff --git a/common/sysutils.c b/common/sysutils.c
index c30f9a0ce..bbed309a8 100644
--- a/common/sysutils.c
+++ b/common/sysutils.c
@@ -1237,10 +1237,20 @@ int
 gnupg_stat (const char *name, struct stat *statbuf)
 {
 # ifdef HAVE_W32_SYSTEM
+#  if __MINGW32_MAJOR_VERSION > 3
+    /* mingw.org's MinGW */
+#   define STRUCT_STAT _stat
+#  elif defined(_USE_32BIT_TIME_T)
+    /* MinGW64 for i686 */
+#   define STRUCT_STAT _stat32
+#  else
+    /* MinGW64 for x86_64 */
+#   define STRUCT_STAT _stat64i32
+#  endif
   if (any8bitchar (name))
     {
       wchar_t *wname;
-      struct _stat32 st32;
+      struct STRUCT_STAT st32;
       int ret;

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

Thank you for reporting, and sorry for late handling of this report.