See https://dev.gnupg.org/T6685#174802

So as a replacement for what we have in Kleopatra this would work.

To be honest. While I get that the customer wishes for even more non standard behavior and I somewhat agree in the case of smime that it makes more sense to encrypt to an expired key.

Hello, I sen you logs.

The nonfunctonal "no date" is gone now in VS-Desktop-3.1.90.267-Beta

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.