Currently we require that each correctponent's key is individually marked as accepted.
We have received a request to offer a mechanism that can be used to mark multiple keys as accepted at once, ideally in a way that works with Thunderbird 78.
We are very limited what new UI we can add on the stable 78 branch (mostly, because we don't want to introduce new user interface text), and also we want to avoid big code changes or big enhancements.
The question is, can we find a way to make this possible with a minimal amount of changes.
Here is a suggestion:
At the time we're importing a set of public keys (e.g. from a file), we currently start by reading the list of keys, and then we show a prompt, asking for import confirmation. Currently this dialog says "Import the following keys?" followed by a short or long list of names and email addresses.
We could extend this dialog by showing an additional check box - which is deselected by default. When checked, we could mark all imported keys as "accepted but unverified".
(This wouldn't change the acceptance state if a key is already present with an acceptance state of rejected or verified.)
The tricky question is, what text should be shown next to the checkbox.
Our choices are
(1) introduce a new english text, which wouldn't get localized, and be shown as english in all localized versions of Thunderbird
(2) use an existing text, which mostly describes what we're doing, which could be slightly inaccurate.
For (2), we could show a combination of the following existing strings:
- above the checkbox, we'd show "Do you accept this key for verifying digital signatures and for encrypting messages?"
- the checkbox label itself would say: "Yes, but I have not verified that it is the correct key."
Alessandro, Magnus, do you think we should use (2) with the above text?
If you're worried about people being misled (because the message is in singular, while we're processing multiple keys, and also because we don't show all the other explanation text usually found in the key details and acceptance configuration), then we'd have to go with (1).
I think (2) might be OK for users who have already seen the key details and acceptance dialog.
We could go on step further, and pref this additional feature off by default. In other words, by default we don't change anything in the UI. We introduce a new hidden pref like "mail.openpgp.enable_experimental_code", false by default. If true, we'd then offer the checkbox described above.
Note that the intention of this bug is to strictly start with an implementation that is suitable for backporting to the 78 branch, and thus needs to use a trade off. We can have a follow-up bug to make it nicer for Thunderbird 90 afterwards.