We need to help the user when composing a message, and we cannot send the message because of OpenPGP problems.

I have a patch that provides the following initial assistance.

On send, if signing is requested but isn't possible because the user's own key is not usable (e.g. expired) show a useful error message.

On send, if encryption is requested but isn't possible, because there are issues with the public key of at least on message recipient, show a useful error message.

Allow the user to view the details of the problem we have with message encryption. This is the purpose of the "security info" dialog that can be opened from within the composer window (click the security button, or use the view menu).

Similar to the existing dialog for S/MIME, the new OpenPGP dialog shows information for the keys of the recipients of the current message.

The dialog will show a listbox with multiple entries.

For each recipient email address, a line with an overall status is shown:

• ok
• !! no key available !!
• !! no accepted key !!

After each list with an email address, a variable number of lines will be shown, either zero, one or multiple lines, depending on how many "potentially valid" keys are available for that address. Potentially valid means, keys that aren't expired and aren't revoked. For each such available key, the current "acceptance" status is shown, which is the user's own decision (remembered) for that key.

Two buttons are shown.

• The button "View details and edit acceptance" can be used to open the key details dialog (same as shown on import or from key manager), which allows the user to change the acceptance status.
• The buton "Discover new or updated key" can be used to query Internet directories for keys of the given email address.

(In a future revision we could allow the "discover" button to specifically search for an updated key of the selected key ID.)

Ride along fixes:

• fix expiry status of keys in key manager and the key object
• remove obsolete code for gnupg validity/trust

Magnus, could you please r+ the patch in phab?

After discussing with Magnus, the dialog is too complex to understand. It seems better to introduce another dialog level.

When opening, we'd show a simpler list, with only two columns. Recipients, and the overall status for that recipient (ok, no key available, not accepted key). There we'd have a button "view keys for selected recipient".

Another dialog would open on top, specifically for the selected recipient. It shows the list of keys, has the discover button, and view details button. Clicking details will open the common key details dialog.

Patrick raised a concern about the use of the term "personal key" vs "own key".

We currently use the term "personal" in the sense of "your own" in OpenPGP preferences and in S/MIME preferences.

The intention of the term "personal key" or "personal certificate" is to describe a key your is owned by yourself.

Patrick is worried that the term "personal" might not sufficiently express that, because it could be interpreted as "a key related to a person, which might be another person".

Is that a valid concern?

Should we avoid the term "personal" and use a better term, like "own key" and "own certificate" everywhere?

I asked on Matrix. Standard8 thinks that the personal "personal key" is clear. He also said, for the meaning that Patrick suggested, one would rather use the term "a person's key".

So should we stay with the term "personal key"?

Or is the potential ambiguity for non-native speakers a reason to prefer the term "own key"?

I'm fine with "personal key" if native speakers think it's clear. But then we should consistently use it throughout the whole application.

I guess there is a bit of risk such things would get translated wrongly too.
Is there a need to state that it's the "personal key". Could we just use "key"?

At least personally (hah!) I didn't get that it meant a key I owned myself.

(In reply to Magnus Melin [:mkmelin] from comment #8)

I guess there is a bit of risk such things would get translated wrongly too.
Is there a need to state that it's the "personal key". Could we just use "key"?

I'd prefer to have "personal key". If we just say "key" then the user might wonder: "I have all those keys showing in key manager, but why is almost none of them offered in the selection?".

(In reply to Magnus Melin [:mkmelin] from comment #9)

At least personally (hah!) I didn't get that it meant a key I owned myself.

Yes, your use of the term "personally" seems to confirm, you think that term refers to yourself :)

(In reply to Patrick Brunschwig from comment #7)

I'm fine with "personal key" if native speakers think it's clear. But then we should consistently use it throughout the whole application.

Agreed. I'll fix.

(In reply to Kai Engert (:KaiE:) from comment #10)

I'd prefer to have "personal key". If we just say "key" then the user might wonder: "I have all those keys showing in key manager, but why is almost none of them offered in the selection?".

I'd think it's pretty understood that you don't use other people's keys for your own purposes - you don't do that physically either.

I've implemented the new two-step approach, the patch is ready for review in phab.

I'll attach screenshots. This is the initial dialog that you get when you click the security info button. It's also used when you try to send encrypted, but can't, because of missing/unaccepted keys.

As you see, in this dialog, you only see an overall status for each recipient, whether the status is ok, or what problem there is.

In order to learn more about the keys for a specific recipient, select it and click the button. That will open another dialog, specific to the selected email address.

That second dialog will list the available keys, and their acceptance status, will allow you to change your acceptance decision, and will allow you to discover keys by searching directories. I'll attach screenshots for the second step for each of the recipients in this example.

Seems like a step in the right direction. The main dialog is now quite understandable.
For the subdialogs, having a large area with a listing seems quite odd. It would be better to just display the information and guide the user on from that. Displaying an empty area doesn't give the user proper input on what to do next I think. An area of this kind would only be appropriate if there are many keys, but the usual case would be one.

(In reply to Magnus Melin [:mkmelin] from comment #18)

Seems like a step in the right direction. The main dialog is now quite understandable.

I've made it less wide, see updated screenshot.

For the subdialogs, having a large area with a listing seems quite odd. It would be better to just display the information and guide the user on from that. Displaying an empty area doesn't give the user proper input on what to do next I think. An area of this kind would only be appropriate if there are many keys, but the usual case would be one.

Thanks for the feedback. I agree.

My initial question was about the general structure of the two dialogs, and IIUC they seem ok to you.

Changing the default size is fine. Also, I agree that we should add more guidance to this dialog.
I'll attach an updated suggestion for further discussion.

We can iterate on the best strings, but it would be nice to land something initially. Note that our strings are still kept separate from localization (in content), so for those strings, we currently can easily commit, then change them again in the upcoming days.

documenting a screenshot of what I'd like to check in as the updated step-2 dialog, after trying to merge in Magnus' succestions.

updated key details dialog, that includes the "avoid to accept rogue key" warning above the acceptance selection.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/cca8ae03b543
Initial user assistance for OpenPGP problems in message composer. r=PatrickBrunschwig,mkmelin

updated to include the follow-up fix

https://hg.mozilla.org/releases/comm-beta/rev/a4c6822ef10da51179aea767abb0b4487e7b86c4

Thanks but it is still not clear how to find a way for user assistance.

There was a failure in key movement from Enigmail to TB 78 and as a result I can not send any emails at all since I always get "Unable to send the message because there is a problem with your personal key" error even though I have all "encrypt" and "sign" settings unchecked, which is really weird.

Is there a way to disable the whole PGP thing for now?

There are lots of "pgp" entries in "about:config" but which is a general one and why there is no regular setting in the user options menu?

Thanks in advance.

Sorry for the inconvenience, you're are probably affected by the issue described in this message post, which also explains how to fix it:
https://thunderbird.topicbox.com/groups/e2ee/T30c6a3b85c865020/for-testers-of-openpgp-configuration-change-required

(In reply to User Dderss from comment #32)

Is there a way to disable the whole PGP thing for now?

mail.openpgp.enable