Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).

This may not be reproducible on Windows for the same reasons as T6813.

Me neither. But I take this since I can better debug this on Windows directly since this seems to be a windows only issue and it might be a build issue.

Not important for VSD 3.2 but yes I would like to see that fixed. Especially since we want the resolver also in KMail.

Fixed with the above two commits.

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.

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

Ok closing, remaining issue is in T6813

This can be also reproduced easily on Linux with test_keyresolver from libkleo:

After reading the initial description of this, I think that might even be a yet a different bug. For which we then would not yet have a ticket. :)

The issue for that is: https://dev.gnupg.org/T6566 so I think this can be resolved here?

No it is just not properly selected after generation but it is there. I think there might even be an issue for that already. But definitely not something related to vsd 3.2

With VS-Desktop-3.1.90.277-Beta the generated key is the default RSA 3072.

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.

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.

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.

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

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.

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.

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.

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:

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

Test version is available intern.

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:

Hello,
I will send the logs as soon as possible.
Thank you.
Daniel

In T6775#177408, @werner wrote:

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.

Yes pretty sure about that, ok we will provide you log, thank you

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.

Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

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.

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:

For sent mails folder there is no solution. The problem is that if the mail never leaves the exchange server it is not converted to a standard compliant PGP/MIME but left in Microsofts internal MAPI format where it looks like this. I think thunderbird has support to fixup a message if the mimetype of the first attachment application/pgp-encrypted. Which reminds me that we need to change the filename of our internal attachment, too to use .mim as an extension. Then you will at least also be able to open such messages on other clients with Kleopatra directly to view the contents of the mail. And a side effect of this might be that Enigmail might then be able to open the mails. If not we would need to talk to enigmail how to solve this.

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

There has been another report on the Gpg4win Forum which might be related that mails now cause endless syncs and might even break further when they are saved back to the same exchange server as there is no MAPI to MIME conversion done anymore and other clients cannot read the mime structure.

that's really cool :) .. I tested now with a mail whole having the Warning message, I press "Show Mail" and it indeed open .. see the pic.
very nice feature indeed.

Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.

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.

Thanks a lot Andre ... I believe it's solved.

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

So the default error is now:

Maybe its not a com addin but one of the New JavaScript webapi addins? They have a different menu to disable. Definetly not an outlook feature its this protectit thingy. But have you now Trierdto open the mail from the Kleopatra menu? That is the cool New feature we are currently working on.

I disable all Addons (see screenshots) and restarted the Outlook, but still getting the same warning when trying to open the email.

Ah wait, in the first of your screenshots it is obvious which addin is modifying your mail so that we don't see it as an encrypted mail anymore. It is that warning text from the protection Addin that you should report that mail if you are unsure where it came from. That would cause such problems because when it inserts this text the type of the mail is changed and it is no longer detected as an encrypted mail.

There in the last screenshot on the right. Btw. since the mail you sent me with the ZIP archive looked also fine to me, there might be another problem here. Could you try disabling your other Addons in Outlook temporarily and check if that might solve the issue? Other addons are also often a cause for some unusual client behavior. You can do that if you go to File -> Options -> Add-Ins -> Manage COM Addins, and then unselect others just for a test.

this is what I'm getting when trying to open the mail then the attachment. Am i missing something?

strange, your test mail in the attachment decrypted for me, too. What happens if you now use the "Show EMail" button?