But I wonder if we should not address https://dev.gnupg.org/T6683#176429, the text there is not changes in this Beta version.

In GnuPG-VS-Desktop-3.1.90.267-Beta-Standard it works, aside from T6805:
You do not get the new "no x509" message wrongly any more even when quickly sending a mail after restart of Outlook.
But it correctly appeares if no X509 is available.
And the message is configurable via the registry setting HKLM/HKCU \Software\GNU\GpgOL\smimeNoCertSigErr (although I do not know how to add line breaks there, but that is not important).

See T6736#177624 for the possible cause of the off-by-one day problem.

The observed behavior is exactly what was requested in T6743

Update: "can encrypt" should determine if an encryption subkey exists for a key in the keyring associated with the given email address. If that key is expired, it should be displayed appropriately marked and the encryption button greyed out.

Well I guess T6805 is now the followup ticket that I did not create when I just closed this issue as Wontfix. Ingo can you take T6805 and do what you wrote in your last message here?

This is an incarnation of T6685 while we decided to deprecate that job we did not open a ticket to do it and forgot about it. So we did not notice that it was still used in the keyapprovaldialog. Fix is to replace it there with the correct key generation job.

I tried to reproduce this but I didn't succeed. I used "Create New OpenPGP Cert" for my attempts.

We consider rsa2048 as compliant until the end of this year; this is required due to the Telesec smartcards. However, we should never create such a key and kleopatra does not allow this.

with VS-Desktop-3.1.90.267-Beta when trying to send a secured mail to the expired Berta X509 testkey I get the confirmation dialog but now the OK button is greyed out:

Thanks, I will test this and if it works as expected I would also put it in 2.2. since it was pointed out to me from a customer at our approval institution and I think they will be glad if they see that this is gone in the next release and I don't see any regression risk associated with that change.

In general, the changes look good.

Pushed the change to master/2.4.

I'm not familiar with phabricator software so perhaps there is a better way to attach a diff to this ticket. Here is the diff I created: https://dev.gnupg.org/differential/diff/1543/

To be honest, the only backup worthy settings file of kleopatra is the kleopatragroupsrc right now. Most other settings are pretty much only for convenience I would not even bother to back them up. When something important is configured by the administration that should go through the registry. As we recently noticed, through talking to people at froscon and with the BSI the most common case was that our kleopatra settings were actually never updated or only saved by accident.

So should we at the moment only change our backup/migration recommendations? Add %LOCALAPPDATA%/kleopatra and %LOCALAPPDATA%/*rc to the backup?

for comparison, the command without compliance enabled:

Well the icons are there. So I don't think this needs more QA.

Test version is available intern.

Fixed.

This will definitely not be changed for 3.2 it will be a very invasive patch with a big regression risk and which does not make real sense to do before we switch to Qt6 since it involves patching Qt.

I guess that it's a case of specifying static passphrase. If so, here is the patch:

diff --git a/g10/call-agent.c b/g10/call-agent.c
index cb7053396..c44c1cddb 100644
--- a/g10/call-agent.c
+++ b/g10/call-agent.c
@@ -161,6 +161,7 @@ default_inq_cb (void *opaque, const char *line)
             || has_leading_keyword (line, "NEW_PASSPHRASE"))
            && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK)
     {
+      assuan_begin_confidential (parm->ctx);
       if (have_static_passphrase ())
         {
           s = get_static_passphrase ();
@@ -187,6 +188,7 @@ default_inq_cb (void *opaque, const char *line)
             err = assuan_send_data (parm->ctx, pw, strlen (pw));
           xfree (pw);
         }
+      assuan_end_confidential (parm->ctx);
     }
   else if ((s = has_leading_keyword (line, "CONFIRM"))
            && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK
diff --git a/sm/call-agent.c b/sm/call-agent.c
index 883c0c644..7f7205f26 100644
--- a/sm/call-agent.c
+++ b/sm/call-agent.c
@@ -222,7 +222,9 @@ default_inq_cb (void *opaque, const char *line)
            && have_static_passphrase ())
     {
       const char *s = get_static_passphrase ();
+      assuan_begin_confidential (parm->ctx);
       err = assuan_send_data (parm->ctx, s, strlen (s));
+      assuan_end_confidential (parm->ctx);
     }
   else
     log_error ("ignoring gpg-agent inquiry '%s'\n", line);

(I also found similar case for gpg as well as gpgsm.)

Pushed the changes for ...sc_op_failure routines to master/2.4.

We would need to revise tools/card-call-scd.c:status_sc_op_failure and g10/card-util.c:write_sc_op_status to catch GPG_ERR_PIN_BLOCKED and GOG_ERR_NO_RESET_CODE.