I need the S/MIME group if I shall look into this. Are you sure that all S/MIME keys in the group can be used for encryption? Groups containing sign-only keys (OpenPGP or S/MIME doesn't matter) are never offered for encryption. That's why we wrote T6722: Kleopatra: Forbid adding non-encryption keys to groups.

That it takes so long the first time is to be expected since we are hitting the dirmngr timeouts. I wonder though why it would be much faster in 3.1.26, if anything i would have expected that the timeouts are now shorter.

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.

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.

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.

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).

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.

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:

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?

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.

When I created the GnuPG VS-Desktop MSI Package I messed up and forgot about a file that Gpg4win writes where to place the config files.

I think this works as intended.

Yeah there were some logic errors with this but I think I caught them all.

While I want to investigate the syntax error in URI since I don't think the testkolabs have a syntax error in their URI the behavior you are describing is completely correct in my understanding:

works

Only compliant algorithms are offered when (re)generating single keys or all keys. In de-vs mode, Brainpool 256 is preselected if the smart card supports it. Otherwise, RSA 3072 is preselected.

I tend to give this high priority since our SecOps state that the creation of non vs-nfd compliant keys is inhibited by our software by default (at least in the UI) I mean no one complained and it is not a regression but this should be fixed soonish. But this does not neccessarily mean before the next release.

Needed changes in Kleopatra are tracked in T6761.

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Well I have looked at this ticket and posted a comment. We should talk about if there is anything left to do or not. I suspect that the gpg side is done and I should open one (or probably better several) ticket(s) for the kleopatra side.

Fixed.

It isn't a duplicate. See T6325#176719.

This is probably a duplicate of T6325

Choosing Curve 25519 results in a general error btw.

We decided to use the blue symbol for such a not compliant key in the VSD version

Form the Gnupg-2.2 commit rG936954a18a2df made sure that the hkps:// prefixing from kleopatra is ignored.

The new "no 509 certificate" message box comes up always when restarting Outlook and then immediately composing and sending a message, even when the user has a certificate.
-> add a check if the cache is already loaded in GpgOL

For the Berta Key in the Testversion: *After* entering the Password for the signature, the new GpgOL message does show. When I choose "Retry" in spite of the warning, the mail is send out encrypted.
So I was only confused because I did expect another order of events. Something seems redundant and confusing here:
First you are shown the security confirmation dialog an click on OK (with the small warning sign and "not compliant" next to it), then you are asked for your password (if it is not in the cache) and then you get the new Warning message with the option to "Retry". Although you already in the first dialog chose to encrypt non-compliant.
Btw: The error message from gpg is for me not "end of file" instead it is: "Syntax error in URI"

If I repeat this with a totally empty keyring, I get the new message regarding the missing signing certificate.

Sorting problematic keys to the front make sense to me, but might be complex since we just add the certificatelineedits and then would need to do some kind of dynamic layouting regarding on the return value of the linedits key.

With this certificate I do get the security confirmation dialog without "always show" on, but still no new message box.

Yes, the wording for this line should be improved, I agree.
In the current release and the releases up to now this action did not work at all when it was not used in combination with encrypt. That usually happens only if an administrator activates the "always_sign" option, prefers S/MIME and then does not issue users with S/MIME certificates. For OpenPGP we have the "Generate" option preselected in that case.

Without "always show" I get a pinentry immediately after hitting "Send". So no warning.

In T6683#176424, @ebo wrote:

I realized that I still had "always show confirmation dialog" on... When I turn that off I get the default error message, but with encoding errors:

I do not see the default error message, not even with a new, totally empty keyring.
I immediately get:

This works insofar that it is now possible to set "none" (via the registry in VSD):

The most difficult thing here was to actually support the case where the user then sees the keyresolver dialog and selects "yes i do not wish to sign" this never worked.

Now when I try to encrypt to expired certificate this message comes up:

So the default error is now:

Btw. if the keyserver is set to "none" or whatever the new value is worded we should remove all the publishing options from the UI. But that is a different issue, I just noticed this while talking about this ticket.

this works now:

@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory

I misunderstood the issue. When I created the GnuPG VS-Desktop package I did not wrote a qt.conf file which thanks to our patch https://dev.gnupg.org/source/gpg4win/browse/master/patches/qtbase/0001-Gpg4win-qstandardpaths-patch.patch caused all config files for Gpg4win to be placed under %APPDATA%\kleopatra. This was by accident since it uses NSIS FileWrite and FileWrite is not supported in our NSIS to MSI packaging.

BTW, with one of the recent gpgme fixes we now get

$~/b/gpgme/tests/run-keylist  --extern --verbose foo
run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available

which is what users (and kleopatra) expects.

Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

I think that might have been some idea we had before we added --require-compliance and proper display of non compliant signatures in KMail and Kleopatra and wanted to ensure that non compliant signatures are not "Green".
But since this is not a regression we might even consider not changing this in 2.2 anymore but instead do some relaxation how we treat non compliant signatures both for creation and verification in 2.4 I see T6644 as related.

I do not agree that this will help much, but I am all for changing the string "Find more info on Wikipedia" into something like "See the Quickguide for a short introduction".