Page MenuHome GnuPG

GpgOL: Improve handling for always sign, when no S/MIME sec key is available
Closed, WontfixPublic

Description

When a user starts from scratch in the configuration:

  • Prefer S/MIME
  • Always sign

He currently will be offered to generate an OpenPGP key when sending the first mail.

This is bad as it might confuse users a lot. As this is the first point of contact for probably many users we need to handle this nicely. A user might want to ignore the dialog, might not know about GpgOL and get angy.

I'm not sure about the solution. The main question is -> should we silently "not sign" in that case or should we warn and if we warn, how aggressive do we want to do this.

As we are limited what we can do in GpgOL itself I think that another gpg4win-tool is in order for this. Putting it into the keyapproval dialog would not be that helpful I think as this is more GpgOL specific.

My proposal is to:

Create a new dialog with a small text:

"GpgOL is configured to cryptographically sign all mails usign S/MIME. A secret key is required for this."

Two large buttons below (similar to kleo first start) with "Import" and "Generate".
Generate would check if all required info for the CSR can be obtained through configuration if so it
will just start to generate, show a progress and exit afterwards, showing a mail window with
the CSR addressed to the configured CA. If the CA is not configured it would show an additional
message.

We can make this feature also available through the GpgOL options or when a certificate is expired.

The closing buttons of the dialog would be:
"Send messages unsigned" "Cancel sending"

Import of a secret key would open close the dialog and continue the certificate resultion.

"Send messages unsigned" will disable this warning for the next 30 mails. After thirty mails the warning will show up again. We can also make this configurable.

Prio High because we currently have a large institution hitting this.

Details

Version
2.3.3

Event Timeline

Mmh no. This needs to go into the resolver. If autoresolve is disabled we also want to have that functionality. Having the ca config in libkleo would also help to use the same values in Kleopatra for a CSR.

We have solved this now by showing a configurable error message in that case instead of hard failure with a cryptic error in T6683: GpgOL: Configurable error if sign is selected and prefer_smime

Currently automatically generating CSRs and sending them out by Mail does not have the relevance anymore as when we created this ticket, since the workflow for at least the original requestor of this feature is now different and cannot be automated by GpgOL.

So I am setting this to wontfix, since the problematic part of this issue with the hard failure and bad user expierence has been fixed, and the convenience feature of automatically generating a CSR is no longer requested.