For an OpenPGP group it looks now like this:

When testing with the viktor-gnupg testcertificate I get the new warning message instead of the not very helpful "no name" error in 3.1.26.
But it takes at least 30 seconds to get to that message (the error message in 3.1.26 came up much faster). And when acknowledging the warning it again takes almost as long as before until the message is sent. And in 2 out of 3 tries the Compose Window remained open, so that it looked like the message was not send. Clicking again on Send did not make anything happen, though. And checking the mailbox showed that the mail was sent already.

That sounds very good.

We are now generating a key with whatever defaults gpg uses.

works. "archive (1).tar.gpg" is now the suggestion on Windows, too. Tested with VS-Desktop-3.1.90.267-Beta

Thanks for the reviews. And your beautiful work, by which I also mean the response to the feedback and how you managed to work with phabricator. I will commit the patch on your behalf then later.

Well in Gpg4win it actually works better :) At least there the configuration files are all in one place (or mostly, or should be). Anyway a difficult issue which I am only planning to touch when we do the migration to Qt6 since this is heavily Qt releated. But the current plan (which might change) is to do that for the GnuPG VSD summer release which will be the next feature release after 3.2.

We discussed this at length again. I would not veto a change that would allow users to encrypt to expired S/MIME certificates but the main use case I had in mind here was with regards to "Some error" happening when encrypting ( like T6545 T6398 ) . So that in the keyresolver everything is green but you cannot encrypt. Or that you have an incomplete certificate chain or an untrusted root certificate and it will take your administration some weeks to mark that as trusted. That makes this feature a bit hard to test so ebo mostly tested with expired certificates. (And I know that technically you can't verify if a cert is expired or not if you have an incomplete chain). A better test will be with a fully valid cert that has an unreachable CRL distribution point. I have such a cert and will give it to ebo. So she can test again and if that works as intended -> Key resolver green -> Error -> Allow to encrypt anyway but not vs-nfd compliant. I think we can set this issue to resolved.
The whole question regarding expired / non expired is a different topic on which, as I said, I changed my mind. You can easily explain to users "You cannot encrypt to expired certificates" but you cannot easily explain "you cannot encrypt to support@greenbone.com because they have unsupported cert extensions in their certitifcate"

I disagree. We already talked about this and we should proceed as planned.

Further investigation showed that this was due to a bogus key creating during I wrote the code.

I think that tried_password_cache in the documentation is wrong. The text:

and @code{tried_password_cache} is false

ok, then I'll add the tag for the VSD release after the upcoming one. It is of course relevant for Gpg4win also, but we do not have a dedicated workboard for that (at least not yet)

Setting back to Testing to get some more debug logs with a build that includes the latest commits.

Thanks for the update.

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.