From your description it is not clear what you did exactly.

I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.

So, what is the state of this. Did a change already land in Kleopatra and how can we assure that all binaries have a W32INFO_PRODUCTNAME in their rc file?

I guess we should put this on the agenda for our next RL meeting.

Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24

• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

I'm putting this back to triage because I cannot act on this ticket. There's way too much text and the outcome what should be done is unclear. Either rewrite the description so that it tells the reader concisely what should be changed and how it should be changed. Or, maybe better, create a new ticket referring to the discussion in this ticket and close this ticket.

In T6708#181592, @werner wrote:

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

Sorry, it was my fault building the test installer.

To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.

Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.

The fix was not included in the Testbuid...

Does not work in Gpg4win-4.2.1-beta178

Note for myself: This is the behavior for key resolving in GpgOL. GpgEX has different code for this and the above examples will not work.
In GpgEX the group is not resolved into its component keys currently.

The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.

works, VS-Desktop-3.1.90.287-Beta

Since I did not have a valid signing cert on that dev keyring I only tested with encrypt,...

Reopened as I noticed that the last testmail had an empty body in my sent folder. And I am sure that I wrote some text. Please check.

Ok. With a simple group with one valid and one expired certificate it looks fine:

works better than I expected. With VS-Desktop-3.1.90.277-Beta now there is no delay any more, neither after nor before the new message window

Well the checkbox is before this dialog. This dialog only comes up if you have checked sign or if your administration has checked sign for you (which they _should_ only do if they also ensure to give you a certificate). But usually this should not come up this way.

I like the explicit check boxes in the file encryption dialog more than this "hidden" combo box entry. (BTW, the file encryption dialog says "sign as" and "prove authenticity (sign)" but in this case there's little potential to confuse "sign" with email signatures. The wording should probably still be unified.)

I am mostly sure that for the majority of our users "sign" means the "signature" of the email. So the bottom text below an email so I try to avoid that wording as much as possible. It is only visible in the "advanced" sub options of GpgOL which I think should only interest people who actually know what the context "sign" means when clicking the button "sign".

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: