When an error occurs during S/MIME mail encryption the user should be offered a yes / no message box, which indicates that we can lower the security checks. Make it non VS-NfD compliant (in VS-NfD) mode and try again to encrypt with. GPGME_ENCRYPT_ALWAYS_TRUST.
Description
Description
Revisions and Commits
Revisions and Commits
| rO GpgOL | |||
| rO48fee63649d7 Do not delete input after sign & encrypt | |||
| rO4845cafa373b When S/MIME encryption is forced use offline mode | |||
| rOe0ef0249da5f Add support for S/MIME always trust | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • aheinecke | T6701 GpgOL: Use GPGME_ENCRYPT_ALWAYS_TRUST | ||
| Resolved | • ebo | T6559 GPGSM: "always trust like override" or "force" option |
Event Timeline
Comment Actions
Now when I try to encrypt to expired certificate this message comes up:
(End of File is the error because the CRL check fails with End of File)
In VS-NfD Mode it will additionally says: WARNING: This mail will not be VS-NFD Compliant as the last line.
Comment Actions
Without "always show" I get a pinentry immediately after hitting "Send". So no warning.
With "always show" I see that the key is expired:
But again no new message box.
Comment Actions
With this certificate I do get the security confirmation dialog without "always show" on, but still no new message box.
But with the following expired "test1" key the mail is sent out without any information at all:
Comment Actions
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"
In contrast: In 3.1.26 with the same invalid Berta S/MIME-Key as above, I get the same security confirmation dialog (without "always show" on) as above, but when choosing "OK" and entering the password for the signature, I get GpgOL info window with "Crypto operation failed: Configuration error". It's the same with the expired test1@testkolab.intevation.de key as recipient.
Comment Actions
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:
- You encrypt to a non-compliant key, so you have the normal "non compliant" behavior.
- This key also has a broken CRL, so encryption fails.
- You get the new "override" option and everything works fine.
I am very happy with that. That you get the pinentry first and then the warning cannot be avoided. Because we try to encrypt / sign normally, for S/MIME this means sign first, then encrypt. So the signing will always work. The encryption then fails and in the error handling we offer to "override" the error.
The bug I digest from your last three messages is that without "Always show" you do not get the key confirmation dialog for an expired key, which you should get as the operation would not be VS-NfD compliant. Is this correct from my understanding?
Comment Actions
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:
My expectation from your previous comments was that I should be able to select OK anyway which would result in popup of a warning window where I could confirm that I want to continue in spite the warning. But for this the Key would have to be considered non-compliant only with the blue information icon, and not the red X one.
Comment Actions
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.
Comment Actions
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 as Ingo has pointed out the path we go down here regarding different behavior for S/MIME and OpenPGP seems wrong. And yes I said it differently in the past but I am known to change my mind when I hear good arguments and I think the argument regarding differences between S/MIME behavior and OpenPGP behavior are valid. An S/MIME key with a broken CRL is like an untrusted PGP key, to which we encrypt just fine. So I don't think the behavior is different in that way.
But when we treat expired keys differently because of the different protocols this seems wrong. Although I could also see the argument that otherwise no encryption will happen. One could also argue then the user must first ask his communication partner for a valid certificate.
So to conclude my thoughts. The behavior you have tested here seems now the correct behavior to me even if I said it differently in the past. So I would put this on resolved.
Comment Actions
I disagree. We already talked about this and we should proceed as planned.
The difference between OpenPGP and X.509 is that for OpenPGP you can easily prolong your key - with X.509 you rely on a third party and experience has shown that this may take weeks before you get the new certificate.
Comment Actions
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"
Comment Actions
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.
Comment Actions
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.
Regarding the second try. I can easily fix that in GpgOL by setting the context to offline if we use always_trust for S/MIME anyway.
That the defunct window stays open :/ that is a veeeeeery deep and problematic issue i only found T5485 but there are probably more. That happens because we block outlook for so long that the window management gets messy. But my fix for this was always to use async encryption. But then we also had this issue which ( T5485 ) is actually about. And when I used async encryption we had some unexpected regressions. I am very unsure that we will ever be able to fix that "defunct window artifact" sometimes. But it is good to know that a very long encryption is a reliable trigger for this, too. Then maybe I could do some Windows window management tricks to close the window if outlook fails to close it.
Comment Actions
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
And as it goes fast now, the send window does not stay open any more, too.
The "unknown host" error is the same as in the last test.
Comment Actions
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.
Comment Actions
Since I did not have a valid signing cert on that dev keyring I only tested with encrypt,...
With sign & encrypt GpgOL threw away the original input data after the signing because it does a sign -> then encrypt.
Fixed now, I tested it with a mail with myself in copy and to viktor gnupg and with an added attachment.
Comment Actions
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.
But I don't want to reopen this issue. Since the problem seems to go deeper as I am also unable now to encrypt to at least some untrusted OpenPGP keys. I have created T6839 instead.