Closed Bug 1644085 Opened 5 years ago Closed 4 years ago

Support automatic multiparty encryption, similar to groups in GnuPG (recipient key aliases for email or domain)

Categories

(MailNews Core :: Security: OpenPGP, enhancement, P1)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(thunderbird_esr78+ fixed, thunderbird87+ fixed)

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
thunderbird_esr78 + fixed
thunderbird87 + fixed

People

(Reporter: flo.sammueller, Assigned: KaiE)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(3 files, 11 obsolete files)

Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin
47 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
Details | Review
TB_78.7.2_OpenPGP_Aliases_MessageSecurityInfo-20210211_22-35-32.png
286.80 KB, image/png
Details
1644085-0225a-esr78.patch
45.21 KB, patch
wsmwk
: approval-comm-esr78+
Details | Diff | Splinter Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

In GnuPG, it is possible to set up groups which serve as aliases for multiple public keys [1]. Those groups can be specified e.g. in a configuration file (~/gnupg/gpg.conf). If the recipient is a group alias, GnuPG automatically encrypts a message to all keys that are assigned to this group.
This is especially useful for multiparty encryption to mailing lists (or rather distribution lists, since all recipients have to be known by the sender).

Enigmail supports multiparty encryption in two ways:

  • It can handle groups defined by GnuPG directly (since it merely calls gpg routines).
  • It provides "Per-Recipient Rules". This makes the assignment of multiple keys to one email address possible. [2]

It currently looks like this functionality will be completely lost in future versions of Thunderbird, and that there will be no adequate workaround. For users of groups (GnuPG) or Per-Recipient Rules (Enigmail), this will be a serious regression.

Therefore, this bug should propose the implementation of such a feature.

[1] https://www.gnupg.org/documentation/manuals/gnupg/GPG-Key-related-Options.html#GPG-Key-related-Options
[2] https://enigmail.net/index.php/en/user-manual/configuration#Per-Recipient_Rules

Attached patch groups.patch (obsolete) — — Splinter Review

This patch is a proof of concept for the implementation of this feature. It looks for a file gpg.conf located in the TB-profile directory and parses the specified groups. Allowed syntax:

group <alias>=recipient1 recipient2 ...

or

group <alias>=recipient1
group <alias>=recipient2
...

where alias and recipientX are email addresses.
If the recipient of a new message is a group alias, the corresponding keys are automatically added.

Thanks Florian. It might be useful to have a mechanism like this, although I'd like to work on it at a later time, after more core functionality has been completed. We might consider to require a pref to be enabled for this to work, and we'll have to decide if this should be indicated in the UI.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 1595231

I agree that the core functionality is the main concern at this time and that this feature could be toggled by a pref. For future reference, concerning the UI, it might be helpful to look into the source code of Enigmail since some of its dialogs can already handle the display of groups.

Attached patch multiparty_encryption.patch (obsolete) — — Splinter Review

Since Magnus wanted to review this patch, I'm providing an updated version that resolves merge conflicts with the current code base (2020-08-13) and that is correctly generated with hg export.

Attachment #9154874 - Attachment is obsolete: true
Attachment #9169818 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9169818 [details] [diff] [review] multiparty_encryption.patch Review of attachment 9169818 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the patch. Some general comments below. I think it's not great that the usefulness of the feature require syncing a file into the Thunderbird directory. Perhaps it would be useful to define a scheme by which such configuration is loaded, so that it's applicable also across domains. Or is there something out there already? E.g. an header with a URL to the configuration file? `X-OpenPGP-Multiparty-Config: https://example.com/openpgp-multiparty.json; Last-Modified="Fri, 14 Aug 2020 07:28:00 GMT"` It would only be allowed to host for @example.com lists on example.com Thunderbird could then fetch this as needed. ::: mail/extensions/openpgp/content/modules/encryption.jsm @@ +127,5 @@ > + // Expand groups if necessary > + var toExpanded = []; > + for (let k = 0; k < result.to.length; k++) { > + var group = EnigmailKeyRing.expandGroup(result.to[k]); > + group.forEach(recipient => toExpanded.push(recipient)); This could use spread (...) so toExpanded.push(... EnigmailKeyRing.expandGroup(result.to[k])); ::: mail/extensions/openpgp/content/modules/keyRing.jsm @@ +1269,5 @@ > + // Do group expansion > + var addressesExpanded = []; > + for (let k = 0; k < addresses.length; k++) { > + var group = EnigmailKeyRing.expandGroup(addresses[k]); > + group.forEach(recipient => addressesExpanded.push(recipient)); same here, could use spread @@ +1406,5 @@ > + loadGroupsFromConfig(); > + return gGroups; > + }, > + > + expandGroup(alias) { I think this should check it never overrides an email we do have a normal key for. @@ +1412,5 @@ > + let aliasFmt = "<" + alias + ">"; > + let recipients = []; > + if (!groups[aliasFmt]) { // is not a group > + return [alias]; > + } else { nit: no else after return please @@ +1413,5 @@ > + let recipients = []; > + if (!groups[aliasFmt]) { // is not a group > + return [alias]; > + } else { > + groups[aliasFmt].forEach(recipient => { nit: forEach is not as efficient as for .. of, so for these cases prefer something like for (let recipient of groups[aliasFmt]) { @@ +1556,5 @@ > EnigmailLog.ERROR("keyRing.jsm: loadKeyList: exception: " + ex.toString()); > } > } > > +function loadGroupsFromConfig() { I think it would be better to have a JSON based configuration file, like ``` [ { name: "Group 1", alias: "list@example.com", recipients: [ "foo@example.com", "bar@example.com" ] }, { name: "Group 2", alias: "list2@example.com", recipients: [ "a@example.com", "b@example.com" ] } ] ```
Attachment #9169818 - Flags: review?(mkmelin+mozilla)

Magnus, thank you for your thorough review. There are many helpful remarks that I will incorporate in a follow-up patch soon.

I think it would be better to have a JSON based configuration file

I agree with your proposal to use a more native structure such as JSON. We are leaving GnuPG behind anyways, so we should take the opportunity to adapt the config to our needs. Maybe Kai can also contribute his opinion to this question.

I think it's not great that the usefulness of the feature require syncing a file into the Thunderbird directory.
Perhaps it would be useful to define a scheme by which such configuration is loaded, so that it's applicable also across domains. Or is there something out there already?

I am not sure I understand this part completely. While it certainly is inconvenient to have the user copy a file into the TB profile directory, I still think the config for this feature should be persisted in there. As we cannot add UI for the proper import of such a config at the moment, this would be something to consider in the future.
In particular, the user should always be aware of the set of keys that are used for encryption before actually sending the message. A mechanism that fetches this config on-the-fly from the web could be considered a potential security/trust issue as it obscures the process of key selection. (Apart from that, one should not have to rely on online resources since they could be unavailable, hidden behind a VPN, etc.)

It would only be allowed to host for @example.com lists on example.com

Considering that the user should be aware of all keys to which the message is encrypted, this restriction seems too strict. Also I am sure that there are many current use cases that would not be possible with this limitation. As a counter example, Enigmail's per-recipient rules do not impose such a constraint on the user. In my opinion, it is important to also reflect those situations and to not leave people with this kind of setup behind.

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

I think it would be better to have a JSON based configuration file, like

[
  { 
    name: "Group 1",
    alias: list@example.com,
    recipients: [
      "foo@example.com",
      "bar@example.com"
    ]
  },
  { 
    name: "Group 2",
    alias: list2@example.com,
    recipients: [
      "a@example.com",
      "b@example.com"
    ]
  }
]

I would actually suggest to replace the part recipients with keys. I.e. instead of recipients: [ "email@somewhere.mail" ] we would have keys: [ "0x1234567890ABCDEF" ]

This would remove the need to check if we already have a valid key for a recipient, and it would be a lot more explicit which key to use.

See Also: → 1659141

This patch is a reworked version of the first one and takes the suggestions of Magnus and Patrick into account. Now, the file multiparty-encryption.json in the TB profile directory can be used in the format

{
    "group1@example.com":
    [
        "recipient1@somewhere.com",
        "0x1234567890ABCDEF",
        "another.recipient@example.com"
    ],
    "group2@domain.de": [...],
    ...
}

One can specify both mail addresses or key IDs to select the keys that shall be used for encryption (some high level functions had to be refactored to also handle key IDs). The current UI still works, and in "View Security Info" I have made an attempt to show both the group aliases and the corresponding keys so that it is clear how the stated keys were selected.
I still reckon that a config file which has to be put manually into the TB profile directory is not something that is feasible in the long term. Nevertheless, we can set the foundation for further work and provide a first solution for those users who currently rely on this feature. Like Kai suggested earlier, until we have a more user friendly solution, this mechanism could also be toggled by a hidden pref.

Attachment #9170892 - Flags: review?(patrick)
Attachment #9170892 - Flags: review?(mkmelin+mozilla)
Attachment #9170892 - Flags: review?(kaie)
Priority: -- → P1
See Also: → 1663406
See Also: → 1661463

Comment on attachment 9170892 [details] [diff] [review]
multiparty_encryption_with_keyid-v1.1.patch

Florian has explained to me that this is only to be considered as a "proof of concept" patch, but it isn't the complete solution, for example. We shouldn't spend time on reviewing a known-to-be-imcomplete patch, while not yet knowing which additional parts are necessary.

Attachment #9170892 - Flags: review?(patrick)
Attachment #9170892 - Flags: review?(mkmelin+mozilla)
Attachment #9170892 - Flags: review?(kaie)

In addition to the mentioned (a) "definition of aliases, that expand to a list of expanded keys" (e.g. using the file formats mentioned in the previous comments), additional related enhancements have been requested:

(b) the ability to automatically import keys from an external source. This could either be done in an indepenednt way, by reading keys from files, where filenames could potentially be based on key IDs. Alternatively, they could be read from an existing GnuPG keyring on the same system, but that would only work on systems that have been set up with GnuPG software accordingly, and we'd have to implement that using the GPGME API.

(c) We'd need to decide if keys that are autmatically used (because of rule definitions) should also be automatically treated as "accepted".

(d) If the answer to (c) is yes, then we'd have to extend our visual presentation of key trust. I think the "override" of trust would be limited to the contexts in which the automatic rules apply, e.g. when composing an email to a defined alias. When viewing the security details of an email while composing, the UI would have to show the special trust. Currently we show status like "Accepted (unverified)". We'd have to introduce a new status label, e.g. "Rule based automatic acceptance".

(e) The individual keys of members of a group alias might be expired or revoked. It has been suggested to treat such failures appropriately. In order to communicate the detailed reason to the user, we'd have to extend the user interface of the "view security info" in composer to show the expanded list of recipients, and display the appropriate status for each of them. We'd also probably have to show information to which alias an entry is related to (e.g. if the user composes an email to two aliases).

(f) We'll have to decide how to handle failures. E.g. if an alias has 10 members, and only key isn't usable, what should be done? Send anyway and exclude that member? Or prevent the user from sending at all? Or even offer the user a choice and invent new UI?

I'm not currently opposing this feature, but I'd like to point out that the complete handling of this feature will require application behavior that could be perceived as confusing by Thunderbird users.

The idea to automatically trust keys doesn't align well with our current model, which requires the user to explicitly decide which keys they accept.

In my opinion, a solution at the mailing list manager level would be much easier to understand, and it could already be used today.

For example, the schleuder.org remailer allows you to setup a dedicated machine that defines the members of mailing lists. A single key is used for the list, so every person sending email only needs to have the list's public key. No synching of information to the user's computer is required.

You could argue there is a disadvantage, because the administrator of the re-mailer computer (running the Schleuder software) can intercept and read all messages. However, I'd like to note that with the mechanism described in this bug, the administrator has similar powers. If the administrator of the key and rules synchronization mechanism has malicious intentions, they can add another member to group definitions, which will also receive the messages. A difference is, with the group definition rules, you will have an audit trail, because the rogue addition of another group member could be discovered.

Florian, could you use a local instance of schleuder.org, instead of your key and rule distribution setup?

Flags: needinfo?(flo.sammueller)

Kai, thank you for your feedback.

I would like to make clear that the further enhancements I discussed with you personally, and that you listed in comment 12, are by no means requirements for this feature. Many of those aspect do not even work in Enigmail/GnuPG currently (e.g. automatic key import from keyserver or WKD for groups) or are merely an issue of convenience (e.g. automatically selecting/disabling key trust). At this time and in this bug, only an alternative mode for key selection that deviates from the currently implemented "one recipient mail address <-> one public key" bijection is proposed, because it is a general solution to the problems described here, in the related bugs 1659141, 1663406, 1661463 and in the Thunderbird e2ee Topicbox channel, and prevents a serious regression from TB68+Enigmail+GnuPG. The patch that I called a proof of concept due to the intentionally minimalistic implementation works just fine with the already existing UI and is not incomplete in terms of the aforementioned expected functionality.

In comment 13, you propose the usage of services like schleuder.org, which reencrypt mail to the actual recipients of mailing lists. While this can be easily used and is certainly better than no encryption at all, it is not end-to-end encryption. With schleuder.org, it is impossible to know the keys that will be used for encryption before sending the message. In case of an attack on this service, nobody would even be able to notice immediately. This is fundamentally different to a key selection mechanism that is based on information persisted on the local machine of the user. You say that in our setup, a similar attack vector exists[*]. This is opposed by the fact that anyone with rogue group definitions would be able to notice if they just check them. Not to mention that our setup is probably special per se, and that there are many users that maintain their gpg.conf manually anyway.

In comment 14, do you mean having each member run an instance of schleuder.org on their local machine? I would have to look into that, but I guess that means still having to maintain a GnuPG keyring and gpg.conf additionally to the TB-internal keyring.

[*] At our organization, each member is expected to run a script that syncs a gpg.conf with the current group definitions from one of our servers to the clients machine. Kai argued that this central server could also be compromised such that each member receives malicious group definitions.

Flags: needinfo?(flo.sammueller)
See Also: → 1666182

Let me emphasize that this is URGENT!

It must be possible to use encryption automatically whenever possible. With encryption turned on by default it must still be simple to switch to non-encrypted in case there are not enough keys. This was ok with enigmail, but with tb 78 I have to click away the warning, find the disabling thing in button or menu and then invoke sending again --- that is too much if I have to do that for each and every email!

It must also be possible to disable "Attaching the public key". (https://bugzilla.mozilla.org/show_bug.cgi?id=1654950)

How shall people be convinced to use encryption if they have to go through these complications? They will (as even I do now!) turn off automatic encryption.

very sad.... We need to find another mail encryption solution now :-/ Enigmail was useful, but with the new integrated solution are so much bugs and missing important features like this, that is not possible to use this in a business or enterprise environment anymore.

Unfortunately I can not assess the quality of Florian Sammüller's proposed patch myself (comment 11), but its ability to bipass the bijection of email address and key is a critical requirement in my professional communication. Without it I am forced to use another email client.

Hence, I would be very grateful if this patch could be considered very soon.

Please add options to select recipient(s), be it by IDs or by mail addresses. I can confirm that me and a lot of collegues and friends would not use Schleuder.org as mailing list encryption tool for the reasons mentioned (security risks and complexity).

I am using TB with Enigmail for more then 10 years now and I love them. I am pretty sure that a lot of people would have to search for other mail clients, if you vote for not adding these features to TB 78.x. At least it should be possible to get this features with an Add-on (don't know if this would make things even more complicated) .

I can confirm that the patch (comment 11) works as intended for the case that there is no bijection of email address and key. Can we look into importing it into the source tree? The benefit would be substantial.

First thanks to all who make TB a reliable mailclient. Once I discovered the perfect GPG-integration with Enigmail, it's my first and only choice since almost I can remember.
The feature "recipient rules" made mail encryption almost seamless and with that it was possible to convince a lot of people using secure mail.

Now that there aren't "recipient rules" any longer, it's hard to keep the motivation high. With TB 78 I feel like we are loosing a master argument for practicing a good thing.

So I hope this comment is read as an underline of the importance of this feature! Thank you.

Per recipient rules are absolutely essential for our day to day emails to email alias like office@yourcompany.com. I cannot understand why TB blocks Enigmail and replaces it with something with _ major _ features missing. The only way forward is to downgrade to 68. What a development!

Hi! Please, implement this. This feature is fundamental to my daily usage. Thank you!

(In reply to Michael Nüsken from comment #16)

Let me emphasize that this is URGENT!

It must be possible to use encryption automatically whenever possible. With encryption turned on by default it must still be simple to switch to non-encrypted in case there are not enough keys. This was ok with enigmail, but with tb 78 I have to click away the warning, find the disabling thing in button or menu and then invoke sending again --- that is too much if I have to do that for each and every email!

It must also be possible to disable "Attaching the public key". (https://bugzilla.mozilla.org/show_bug.cgi?id=1654950)

How shall people be convinced to use encryption if they have to go through these complications? They will (as even I do now!) turn off automatic encryption.

Agreed. :+1:

Dear developers,

please include per recipient rules as quickly as possible. The update of Thunderbird has broken secured workflows, because Enigmail is not working and the included GPG solution is not valid replacement.

Thanks!
N

I migrated back to TB 68 for the lack of recipient rules. Enigmail did it quite fine, so please try to advance on that basis.

(In reply to vv01f from comment #26)

I migrated back to TB 68 for the lack of recipient rules. Enigmail did it quite fine, so please try to advance on that basis.

Ah, interesting. I didn't know that was possible. I thought that the update from 67 to 68 changed the .thunderbird directory in a way that wasn't backwards compatible.

(In reply to Andrew Haley from comment #27)

Ah, interesting. I didn't know that was possible. I thought that the update from 67 to 68 changed the .thunderbird directory in a way that wasn't backwards compatible.

ideed that is possible if you take backups seriously. so for having that option you may need to keep a copy of your profile for older versions intact. in this case the lacking adoption of TB 78 also acts as a warning not to upgrade in a hurry. In debian pinning also is a great help to keep the version that works in place. The download package extracted is sufficient for testing aside the distributions packaging manager while still waiting for features in a aproduct to be available (again).

This update ruined my life. I can no longer send secure emails on company lists, I can no longer send email to people with an email different from the one registered in the key. It sucks!

This really needs to be resolved in a hopefully timely manner. All my contacts are in companies that are using general keys and not personal ones. I am not able to communicate securely with them. At least not via Thunderbird.

(In reply to Florian Sammüller from comment #9)

I think the patch provided by Florian will do the job - if a howto is added to the Thunderbird FAQ (like the advanced setup for Smartcards). A "simple" (JSON) configuration file where the respective aliases to be used with key id xyz are provided.

A lof of companies e.g in the finance sector decrypt the messages at a central gateway and then forward them internally to the respective recipient. As far as I remember PGP keys can handle aliases but that would require you to renew / update your keys everytime someone joins / leaves your organization.

Assignee: nobody → kaie

Sorry for not having made progress on this bug earlier, but we have a lot of work around OpenPGP.

Considering earlier comments and after more brainstorming, I consider the following approach, which is designed as a minimal, initial step, because we're limited in what changes can be reasonably made on the stable 78.x branch. An additional constraint is that the changes on 78.x shouldn't be in contradiction with future enhancements, so it's necessary to be careful with the initial step.

Based on the feedback received, users clearly want an aliasing solution, to map an email address (or domain) to keys (one or many).
We should use a solution that solves both this bug (one-to-many aliases) and bug 1663406 (one-to-one aliases and many-to-one aliases).

All alias rules are based on an email address added in the email composer. Each alias address could resolve to one or multiple keys.

I'd like the alias rules to be explicit. I'd like to avoid having to do multiple levels of rule resolution. I suggest that each rule maps to key fingerprints (not IDs, not other email addresses).

I think that eventually we need to have user interface to manage alias rules. But for 78.x we cannot add it. However, we can try to introduce a storage format that is extensible, and can work with an initial set of definitions, and can later be reused and expanded. Using a JSON file seems appropriate.

I'd like the configuration file to be disabled by default, and instead require the user to perform a configuration to enable the external config file with alias rules. We had said it's best if external synchronization solutions don't need to find the Thunderbird profile directory. I suggest that we introduce a new preference, e.g. mail.openpgp.alias_rules_file which can either be a full path, or a simple simple filename. If it's a simple filename (no directory separator characters), then we attempt to load the file from the profile directory. To enable aliases, the user must set the pref once to define which file will be used. (In a future TB version this could be set using UI.)

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

Today, we require that keys are accepted. From today's user interface it might not be obvious - but the acceptance configuration is in fact based on pairs of key and email address. That means, even if a key is accepted, we restrict its use to the list of email addresses that have been presented to the user, at the time the user made the acceptance decision.

That means our usual acceptance rules don't work for aliases. I suggest that we ignore the usual acceptance settings for aliases. The fact that an alias was defined can be considered as accepting the key for the alias.

With one exception: If a key has been marked as rejected, what should we do? I suggest to forbid the use of rejected keys for aliases, too.

I suggest that an alias definition overrides the usual direct key lookup. If an alias is defined, we always use it, and we don't attempt to perform a direct lookup by email address.

An alias rule can go wrong. One or multiple of the defined keys might be missing or expired or revoked, or not have a usable encryption key etc. I suggest that each alias rule needs an optional parameter "ignore_failures". If false, any missing or unusable key will result in a failure and the email not sent. If true, missing or unusable keys will be silently ignored, and only usable keys will be used.

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer window. Currently, for each recipient address, we show a status like "ok" or "no key available".

I suggest that we show "ok" if the alias definition is fine (no failures or set to ignore failures). I found we have an existing string in the codebase that we could reuse for all failure scenarios: "Alias problem" (found in the ldap code).

In this status dialog, I suggest that for each email address that is detected as having an alias configuration, we simply disable button "manage keys for selected recipient" for the initial implementation step. We can later develop a better UI for that.

There is the additional angle of "how do I get the keys" that are defined in alias rules. I'd like to keep that as a separate task for later, outside the scope of this bug.

Please give feedback if this initial approach could be sufficient for your urgent needs, or if something important is missing with this approach.

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

With one exception: If a key has been marked as rejected, what should we do? I suggest to forbid the use of rejected keys for aliases, too.

If a key is rejected for any email address, we'd not allow its use for any alias.

I suggest that an alias definition overrides the usual direct key lookup. If an alias is defined, we always use it, and we don't attempt to perform a direct lookup by email address.

However, I think we can allow that an email address matches both a domain alias rule, and an individual email address rule, and we'd use the list of keys from both rules.

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

Based on the feedback received, users clearly want an aliasing solution, to map an email address (or domain) to keys (one or many).
We should use a solution that solves both this bug (one-to-many aliases) and bug 1663406 (one-to-one aliases and many-to-one aliases).

Great. Thanks for working on this!

I'd like the alias rules to be explicit. I'd like to avoid having to do multiple levels of rule resolution. I suggest that each rule maps to key fingerprints (not IDs, not other email addresses).

Is there a reason why key fingerprints would allow a better rule resolution than key ids? I fear that forcing users to find and select fingerprint blocks will not help to encourage them to use the alias tool.

I think that eventually we need to have user interface to manage alias rules. But for 78.x we cannot add it. However, we can try to introduce a storage format that is extensible, and can work with an initial set of definitions, and can later be reused and expanded. Using a JSON file seems appropriate.

Agree, but I would still suggest to work on UI with high priority in order not to loose too many users.

I'd like the configuration file to be disabled by default, and instead require the user to perform a configuration to enable the external config file with alias rules. We had said it's best if external synchronization solutions don't need to find the Thunderbird profile directory. I suggest that we introduce a new preference, e.g. mail.openpgp.alias_rules_file which can either be a full path, or a simple simple filename. If it's a simple filename (no directory separator characters), then we attempt to load the file from the profile directory. To enable aliases, the user must set the pref once to define which file will be used. (In a future TB version this could be set using UI.)

I can live with that, as long as you provide a clear description of how to write the alias JSON file and where to store it.

An alias rule can go wrong. One or multiple of the defined keys might be missing or expired or revoked, or not have a usable encryption key etc. I suggest that each alias rule needs an optional parameter "ignore_failures". If false, any missing or unusable key will result in a failure and the email not sent. If true, missing or unusable keys will be silently ignored, and only usable keys will be used.

Yes. I would suggest to set ignore_failures=0 as default and document it properly.

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer window. Currently, for each recipient address, we show a status like "ok" or "no key available".

I suggest that we show "ok" if the alias definition is fine (no failures or set to ignore failures). I found we have an existing string in the codebase that we could reuse for all failure scenarios: "Alias problem" (found in the ldap code).

Great.

In this status dialog, I suggest that for each email address that is detected as having an alias configuration, we simply disable button "manage keys for selected recipient" for the initial implementation step. We can later develop a better UI for that.

Agree.

There is the additional angle of "how do I get the keys" that are defined in alias rules. I'd like to keep that as a separate task for later, outside the scope of this bug.

Yes, if user can work with the alias file they should be able to take care about getting the neccessary keys, too.

Once more, thanks a lot for taking care about this feature request!

(In reply to dnk089 from comment #34)

Is there a reason why key fingerprints would allow a better rule resolution than key ids? I fear that forcing users to find and select fingerprint blocks will not help to encourage them to use the alias tool.

In the past, 8-hex-digits key IDs were common, but are now considered insecure, because of potential collisions.
I want to avoid that the same will happen with 16-hex-digits, and that we must consider existing configuration files as ambiguous.
Using full fingerprints can avoid that.

(In reply to dnk089 from comment #34)

I can live with that, as long as you provide a clear description of how to write the alias JSON file and where to store it.

See the attachment.

Attachment #9189596 - Attachment description: tb78-openpgp-alias-sample.json → tb78-openpgp-alias-sample.json definition and example
Attachment #9189596 - Attachment filename: tb78-openpgp-alias-sample.json → tb78-openpgp-alias-sample.json.txt
Attachment #9189596 - Attachment mime type: application/json → text/plain

Hi Kai,

I do not understand why you try to reinvent the wheel. There is already a way to define aliases or to have configuration for pgp/gpg encryption. On a unix box it is the .gnupg/gpg.conf. Aliases or groups can be easily defined there. Another "new" standard is not really userfriendly, as it would mean to maintain two configurations (when using another email client parallel to TB).

Next, Enigmail had already included a quite good key management and configuration for per-recipient-rules. Most of your questions might have been answered already by the developers of Enigmail.

Please consider that users might be confused when migrating from Enigmail to the new TB-encryption tool when it behaves completely different and unexpected. This includes also the per-recipient-rules.

Nevertheless, thank you very much for considering this "bug" and attempting to solve it.

Best wishes
Norbert

Hey Kai,

thx for working on this issue. In general I can work and live with the resolution you described. Howver I agree with dnk089 that this should be moved to UI in the not too far future.

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

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

Just to make sure that I understood your resolution completely...what happens when I receive an encrypted message from abc@abc.com that was encrypted using companykey@abc.com? Will I be able to both read (decrypt) the message and reply to it by using abc@abc.com as recipient but the companykey@abc.com (as configured in the JSON)?

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer >window. Currently, for each recipient address, we show a status like "ok" or "no key available".

How about "ok - alias used"? That would at least show the user that something happened outside the normal proceedings (and that the user configured aliases and may have forgot about it in the meantime).

Thx :-)

(In reply to Pucicu from comment #37)

I do not understand why you try to reinvent the wheel. There is already a way to define aliases or to have configuration for pgp/gpg encryption. On a unix box it is the .gnupg/gpg.conf. Aliases or groups can be easily defined there. Another "new" standard is not really userfriendly, as it would mean to maintain two configurations (when using another email client parallel to TB).

.gnupg/gpg.conf is a private configuration file of the GnuPG software. The GnuPG developers could decide to change their format at any time (and use a migration logic between versions), as it has been done with keyring files in the past. Thunderbird would be required to follow all changes made between GnuPG version, have its own parser for reading the file, and users would experience a broken configuration, if using a newer GnuPG with a Thunderbird version that hasn't been updated to read the new file yet.

And the needs of Alias definitions aren't limited to reading. Assuming Thunderbird will get user interface for managing alias definitions, Thunderbird will need to store updated definitions. Your suggestion would require Thunderbird to change the GnuPG configuration files. That might break GnuPG, if Thunderbird does something that isn't expected by a corresponding GnuPG version. Also, we'd risk corruption if gnupg and Thunderbird attempts to modify the files in the future. Furthermore, Thunderbird might need to store attributes that GnuPG doesn't offer.

In my opinion, because of these reasons, Thunderbird shouldn't try to reuse configuration files that are defined and owned by other software.

(In reply to HyperPac from comment #38)

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

Just to make sure that I understood your resolution completely...what happens when I receive an encrypted message from abc@abc.com that was encrypted using companykey@abc.com? Will I be able to both read (decrypt) the message and reply to it by using abc@abc.com as recipient but the companykey@abc.com (as configured in the JSON)?

The discussion here is only about encrypting and sending.

Decryption is always possible if you have the respective private key.
For decryption, it doesn't matter who sent the message, or to which email address it was sent.

If you want to reply to a message and encrypt it, the suggested system would allow you to define an alias rule, to encrypt using a key that doesn't match any of the user IDs in the key.

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer >window. Currently, for each recipient address, we show a status like "ok" or "no key available".

How about "ok - alias used"? That would at least show the user that something happened outside the normal proceedings (and that the user configured aliases and may have forgot about it in the meantime).

The issue here is localization on a stable branch. We're trying to find a solution for the Thunderbird 78 version, which already has completed its localization period. We're trying not to add new strings on the stable branch, because we cannot easily get translations of additional user interface text. (It's a tooling and coordination problem.)

If we want to offer a solution for the stable 78.x branch, it's best if we find a way to avoid new text.

Once we're done with improvements that are intended for backporting to 78.x, we can later work on improvements to make the text better for future versions like Thunderbird 90 (summer 2021).

That's why I suggest that we simply use "ok", because we already have that text (and its translations). We don't have the text "ok - alias used" that you are suggesting on the 78.x software branch.

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

(In reply to HyperPac from comment #38)

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

Just to make sure that I understood your resolution completely...what happens when I receive an encrypted message from abc@abc.com that was encrypted using companykey@abc.com? Will I be able to both read (decrypt) the message and reply to it by using abc@abc.com as recipient but the companykey@abc.com (as configured in the JSON)?

The discussion here is only about encrypting and sending.

Decryption is always possible if you have the respective private key.
For decryption, it doesn't matter who sent the message, or to which email address it was sent.

If you want to reply to a message and encrypt it, the suggested system would allow you to define an alias rule, to encrypt using a key that >doesn't match any of the user IDs in the key.

Thx for the explanation. I just want to make sure, that the current (working) implementation for decrypting is not broken by the aliases implementation for sending (encrypting).

Blocks: 1679301
Attached patch keyring-import-alias.patch (obsolete) — — Splinter Review

If you try to apply the phabricator patch to comm-central, you'll notice that one small piece is rejected. Apply this patch on top of it to fix it.

(Because the phabricator patch is based on comm-esr78.)

(In reply to HyperPac from comment #38)

How about "ok - alias used"? That would at least show the user that something happened outside the normal proceedings (and that the user configured aliases and may have forgot about it in the meantime).

You've inspired me to look for a different solution.

Instead of showing a text like "ok" (which would have to be localized), we could use a symbolic display (again, we're talking about the initial step suitable for the stable branch).

I'm suggesting that we show "a -> b". We'll obviously need a HOWTO document that will explain how to use the hidden alias feature on the 78 branch, and it can explain that this symbol means "an alias definition is being used".

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

Considering earlier comments and after more brainstorming, I consider the following approach, which is designed as a minimal, initial step, because we're limited in what changes can be reasonably made on the stable 78.x branch. An additional constraint is that the changes on 78.x shouldn't be in contradiction with future enhancements, so it's necessary to be careful with the initial step.

nice that things will be thought through.

Based on the feedback received, users clearly want an aliasing solution, to map an email address (or domain) to keys (one or many).
We should use a solution that solves both this bug (one-to-many aliases) and bug 1663406 (one-to-one aliases and many-to-one aliases).

glad to read that.

I'd like the alias rules to be explicit. I'd like to avoid having to do multiple levels of rule resolution. I suggest that each rule maps to key fingerprints (not IDs, not other email addresses).

fingerprints is the best you can do, also consider that for identifying the signer of a message (clearly stating that pgprules is the origin for the connection).

I'd like the configuration file to be disabled by default, and instead require the user to perform a configuration to enable the external config file with alias rules. We had said it's best if external synchronization solutions don't need to find the Thunderbird profile directory. I suggest that we introduce a new preference, e.g. mail.openpgp.alias_rules_file which can either be a full path, or a simple simple filename. If it's a simple filename (no directory separator characters), then we attempt to load the file from the profile directory. To enable aliases, the user must set the pref once to define which file will be used. (In a future TB version this could be set using UI.)

I dont thing changing the path to the config file helps. Rather I'd suggest to have a directory and enable rules to be split over files for users to manage them. That enables to exchange sets of rules and later can expand on having rules stored elsewhere e.g. in a company. think modular.

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

why not letting users decide on signatures on a per-receipient basis?
aliases could configure several other things as well. we had PGPMime, sign, encrypt and negateRule in Enigmail.
We could easily think of having plaintext/html and other settings such as (list of) places for updated keys attached to that later on. again, think modular, don't block future development early on.

With one exception: If a key has been marked as rejected, what should we do? I suggest to forbid the use of rejected keys for aliases, too.

rejected locally and revoked explicitly yes, expired best not entirely. keys expire quite easily but new keys are not available quite often, so encrypting to an expired key is less a problem than transmitting messages in cleartext. this would be a subject for a warning message but still be much better than blocking usage of keys completely.

I suggest that an alias definition overrides the usual direct key lookup. If an alias is defined, we always use it, and we don't attempt to perform a direct lookup by email address.

with Enigmail we had possibility to match many rules, here you intend to limit for the first match? (better first than last) if no match was found will there still be a lookup? (hope for yes) and can I disable automatic lookups? (hope for yes and disabled remote lookup by default)

An alias rule can go wrong. One or multiple of the defined keys might be missing or expired or revoked, or not have a usable encryption key etc. I suggest that each alias rule needs an optional parameter "ignore_failures". If false, any missing or unusable key will result in a failure and the email not sent. If true, missing or unusable keys will be silently ignored, and only usable keys will be used.

  • failure: unsupported algorithms, defect key, …
  • blocking warning: revoked, locally disabled key
  • non-blocking warning: expired key

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer window. Currently, for each recipient address, we show a status like "ok" or "no key available".

with Enigmail we had an optional dialoque where keys could be (un)selected or updated
that occured e.g. when the amount of addressees and keys did not match or optionally always.

I suggest that we show "ok" if the alias definition is fine (no failures or set to ignore failures). I found we have an existing string in the codebase that we could reuse for all failure scenarios: "Alias problem" (found in the ldap code).

maybe list all matching keys found for aliases and (plan to) add direct access for editing the rules conveniently – until the gui is there, give sufficient information that enables to edit the configuration and recheck again before sending.

There is the additional angle of "how do I get the keys" that are defined in alias rules. I'd like to keep that as a separate task for later, outside the scope of this bug.

this can be (a future) extension for that configuration, e.g. a list of locations (think key-url on a website as well as keyservers)
same for connection to address book entries.

Please give feedback if this initial approach could be sufficient for your urgent needs, or if something important is missing with this approach.

thanks for considering actual usecases

(In reply to vv01f from comment #45)

I'd like the alias rules to be explicit. I'd like to avoid having to do multiple levels of rule resolution. I suggest that each rule maps to key fingerprints (not IDs, not other email addresses).

fingerprints is the best you can do, also consider that for identifying the signer of a message (clearly stating that pgprules is the origin for the connection).

I'd like to declare handling of aliases for signing/verification as out of scope of this bug, and defer to a later time. Would be good to file a separate bug with suggestions.

I'd like the configuration file to be disabled by default, and instead require the user to perform a configuration to enable the external config file with alias rules. We had said it's best if external synchronization solutions don't need to find the Thunderbird profile directory. I suggest that we introduce a new preference, e.g. mail.openpgp.alias_rules_file which can either be a full path, or a simple simple filename. If it's a simple filename (no directory separator characters), then we attempt to load the file from the profile directory. To enable aliases, the user must set the pref once to define which file will be used. (In a future TB version this could be set using UI.)

I dont thing changing the path to the config file helps. Rather I'd suggest to have a directory and enable rules to be split over files for users to manage them. That enables to exchange sets of rules and later can expand on having rules stored elsewhere e.g. in a company. think modular.

It has also been suggested to allow to use URLs instead of local file. Scanning an URL that represents a directory for multiple files is difficult.

It sounds like we need a solution that allows multiple files, and could work with both.

I suggest that we allow the pref to be a mixed list of multiple filenames or directories (later) or URLs (later).
Directory scanning and URLs could be done later.

Aliases should be used for sending encrypted messages, only. They should have no effect on the signature status of received messages.

why not letting users decide on signatures on a per-receipient basis?

signature status -> later

The details of a signature status would have to explain that an alias rule was involved.

aliases could configure several other things as well. we had PGPMime, sign, encrypt and negateRule in Enigmail.
We could easily think of having plaintext/html and other settings such as (list of) places for updated keys attached to that later on. again, think modular, don't block future development early on.

By using the JSON format for storing rules, we can allow additional attributes to rules in the future.

With one exception: If a key has been marked as rejected, what should we do? I suggest to forbid the use of rejected keys for aliases, too.

rejected locally and revoked explicitly yes, expired best not entirely. keys expire quite easily but new keys are not available quite often, so encrypting to an expired key is less a problem than transmitting messages in cleartext. this would be a subject for a warning message but still be much better than blocking usage of keys completely.

Clearly the creator of a key doesn't want you to use a key after it expires. I think we shouldn't use expired keys. If there's a strong reason to allow an override, I suggest to handle that as a potential followup and discuss in a separate ticket. The JSON format would allow us to add such attributes to rules, we don't have to make the final decision now.

I suggest that an alias definition overrides the usual direct key lookup. If an alias is defined, we always use it, and we don't attempt to perform a direct lookup by email address.

with Enigmail we had possibility to match many rules, here you intend to limit for the first match? (better first than last) if no match was found will there still be a lookup? (hope for yes)

An alias must either be defined for an exactly matching email address, or for a domain.

I had not yet considered the scenario of having multiple rules for the same email or domain. If using a single file, I'd consider that a logic error in the definition. When allowing multiple files, the risk for having multiple rules for the same email/domain increases.

Starting with the policy "first rule wins" is hopefully reasonable. It seems that conflicting rules for the same email/domain should be avoided.

and can I disable automatic lookups? (hope for yes and disabled remote lookup by default)

With lookup, I was referring to the lookup for a key with an email address match in the local key store.
At this time we never lookup online automatically. If we'd add this at a future time, it would make sense to allow it to be controlled in alias rules.

An alias rule can go wrong. One or multiple of the defined keys might be missing or expired or revoked, or not have a usable encryption key etc. I suggest that each alias rule needs an optional parameter "ignore_failures". If false, any missing or unusable key will result in a failure and the email not sent. If true, missing or unusable keys will be silently ignored, and only usable keys will be used.

  • failure: unsupported algorithms, defect key, …
  • blocking warning: revoked, locally disabled key
  • non-blocking warning: expired key

Do we really need this complexity, that you define rules for the various kind of failures?
In any case, I think this should be done later.
We could define (at a future time) that a rule can either use the generic ignore_failures rule, or must use alternative fine grained rules for failure handling.

We need at least a minimal amount of feedback when the user opens the "message security info" (clicks the security button) in the composer window. Currently, for each recipient address, we show a status like "ok" or "no key available".

with Enigmail we had an optional dialoque where keys could be (un)selected or updated
that occured e.g. when the amount of addressees and keys did not match or optionally always.

I think that dialog was confusing, and only suitable for very advanced users.
If we really need a complex user interface to give advanced users this kind of interactive control, we'll have to discuss it at a later time, in a bug that targets future versions.

I suggest that we show "ok" if the alias definition is fine (no failures or set to ignore failures). I found we have an existing string in the codebase that we could reuse for all failure scenarios: "Alias problem" (found in the ldap code).

maybe list all matching keys found for aliases and (plan to) add direct access for editing the rules conveniently – until the gui is there, give sufficient information that enables to edit the configuration and recheck again before sending.

The best we can do in 78 is to have english messages on the error console.
It would also require reloading of the file at runtime, which I had hoped to also skip initially.

BTW thanks for the detailed feedback and suggestions.

(In reply to vv01f from comment #45)

aliases could configure several other things as well. we had PGPMime, sign, encrypt and negateRule in Enigmail.

This is a different kind of rules, not aliases.

You're suggesting to automatically influence the way an email will be sent, depending on the recipients. That's a separate kind of complexity, and with more room for potential conflicts between rules.

If we need that class of rules, it's a separate task, more like an automation feature. It seems out of scope for this recipient-alias bug.

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

I suggest that we allow the pref to be a mixed list of multiple filenames or directories (later) or URLs (later).

Could be worth having the pref value be a file:// url or anything else, that fetch() can handle.
But I don't think we want to support multiple sources. That would mean lots of complications in the future (say, where would you save rules?)

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

You're suggesting to automatically influence the way an email will be sent, depending on the recipients. That's a separate kind of complexity, and with more room for potential conflicts between rules.

If we need that class of rules, it's a separate task, more like an automation feature. It seems out of scope for this recipient-alias bug.

you are right; there is a class of rules already for this on a per-domain-basis with settings/composition, button "Send-Options…" which doesnt allow a rule per-address.

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

I'm suggesting that we show "a -> b". We'll obviously need a HOWTO document that will explain how to use the hidden alias feature on the 78 >branch, and it can explain that this symbol means "an alias definition is being used".

I had to think about "a -> b" quite a bit but then I read "an alias definition is being used" and it all made sense :-).

I´m not an expert on localization, but wouldn´t that require localization too, e.g. for Arabic?

Thank you Kai for picking this up again and incorporating all the ideas that were mentioned before. I think the concept that you have presented in comment 32 is very sound and solves all difficult aspects in this regard, especially how to deal with Thunderbird's acceptance model and error handling.

Of course, the presented approach could also be suitable for many other features, e.g. those laid out in comment 45. But remember that the initial goal of this bug was merely to have a replacement for GnuPG's groups or Enigmail's Per-Recipient Rules. I therefore agree with Kai to focus on the essential work that needs to be done to incorporate this feature and keep it as simple as possible for the moment (while still having options to extend it in the future). In my opinion, this means having only one alias definition file, having the user be responsible for its correct content, avoiding a different control flow for key rejection/error handling where possible and not providing an automated import mechanism (keyserver/WKD) for keys connected to an alias.

Two small remarks:

  • The probability of a key ID collision decreases exponentially with increasing key ID length. 64bit key IDs (16 digits) should suffice and make the configuration file more maintainable. At least they should be a valid option alongside whole fingerprints.
  • As Kai already suggested in comment 44, the key selection due to an alias rule can already be indicated in the current UI using a scheme like "alias -> key" - see also my last patch for a similar idea. But I guess that means showing the selected key IDs explicitly because that is the only thing we know from the JSON configuration (remember that we only specify those, not mail addresses). Maybe there could be some kind of lookup that displays the mail addresses or UIDs corresponding to the key ID in the UI instead.

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

Could be worth having the pref value be a file:// url or anything else, that fetch() can handle.
But I don't think we want to support multiple sources. That would mean lots of complications in the future (say, where would you save rules?)

Looks like we have some conflict here, which I had not noticed earlier.

We need a way to load external rules, and Magnus requested it should be possibly to specify an URL.

But we also need a location to store the rules that could be modified/edited/created from within Thunderbird (using future UI), and that location cannot be an URL. We'll need a path that is guaranteed to be writeable, and an URL doesn't give us that guarantee.

I suggest the following approach:

  • we go back to my original suggestion from comment 32, the pref defines a single value, which is exactly one filename (absolute or in profile)
  • it cannot be an URL
  • later, we extend the structure of that JSON file, and allow the addition of entries to define additional read-only locations from which external rules may be loaded.

(In reply to Florian Sammüller from comment #51)

  • The probability of a key ID collision decreases exponentially with increasing key ID length. 64bit key IDs (16 digits) should suffice and make the configuration file more maintainable. At least they should be a valid option alongside whole fingerprints.

While working on the code, I got the impression that the used APIs will accept the short key IDs, too. We'll have to test if it works already.

  • As Kai already suggested in comment 44, the key selection due to an alias rule can already be indicated in the current UI using a scheme like "alias -> key" - see also my last patch for a similar idea. But I guess that means showing the selected key IDs explicitly because that is the only thing we know from the JSON configuration (remember that we only specify those, not mail addresses). Maybe there could be some kind of lookup that displays the mail addresses or UIDs corresponding to the key ID in the UI instead.

The proposed solution to show a symbolic "a -> b" as a shortcut to mean "there is some alias magic going on" is very simple to do.

If you want something more detailed, we'd have several difficulties to handle.

An alias can resolve to many keys. So we'd have to have multiple entries, one for each defined alias recipient key.

The user would then expect that the display gives complete information. What would we do for ignore keys, because they are missing and the rule allows us to ignore failures? We'd need additional ways to explain that, which is tricky with our idea to avoid new explanation text on the stable branch.

Your suggestion to resolve key IDs to user IDs or email addresses has the problem that it's ambiguous, because there could be multiple keys for the same user address. So we'd have to display the key ID (or fingerprint) in addition to the resolved user id or email..

I think that's going to far for now. If you're defining aliases while we don't have UI yet, you have to know what you're doing.

If you really need to debug the effect of an alias resolution, there is a mechanism you could use - which we could document in the HOWTO for the alias feature:

The debugging mechanism is: Compose a test email to the intended recipients and aliases. Enable encryption. Then use the "file send later" function. This won't send the email, but rather store a prepared email in the local folder outbox. You can click that message, open the security details, and you'll see to which recipients the message is encrypted.

Magnus, I have addressed most of your comments from the review, and have updated the patch. I also have some comments and questions, see phabricator. Could you please reply to the questions, and if appropriate re-review? Thanks

Flags: needinfo?(mkmelin+mozilla)
Attachment #9189596 - Attachment is obsolete: true

While we're still working on some details of the code, I would like to invite you to test the proposed enhancement and give feedback, if it works for you or doesn't.
I've prepared instructions here:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

I've commented on D97973.

Flags: needinfo?(mkmelin+mozilla)

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

While we're still working on some details of the code, I would like to invite you to test the proposed enhancement and give feedback, if it works for you or doesn't.

I gave it a shot, and I'm delighted to report it worked. That is sending a message to an encrypted mailing list with 23 members.
Thank you!

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

While we're still working on some details of the code, I would like to invite you to test the proposed enhancement and give feedback, if it works for you or doesn't.
I've prepared instructions here:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

I also tried the build with an alias rule json and it worked great for me. Thanks for working so much on this!
I would love to see the feature in TB 78.7!

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

While we're still working on some details of the code, I would like to invite you to test the proposed enhancement and give feedback, if it works for you or doesn't.
I've prepared instructions here:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

Thank you very much for your effort. I succeeded to send my first test mail using the alias feature out of the box. Works perfectly fine. Alias overrides the trust setting as intended, like you described further above.

However, within your wiki page, the link to the macOS build seems to be wrong. Points to a Linux tarball.

Thank you, Kai. I haven't been able to test it. I'm using macOS but the downloaded experimental TB offered at https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases seems to be compiled for another OS.

I was checking the explanation for creating the json file. In TB's key manager, we can easily copy the key ID, but it has the format of "0xNNNNNNNNNNNNNNNN" with 16 digits after the "0x". It would be most convinient when the json file will use exactly this format, i.e. the key ID as provided by the key manager. Thanks!

Now that TB78.6.1 is out, how is this moving forward?
Will there be a new experimental build with the alias functionality on top of TB78.6.1?
Or will the alias functionality be incorporated into the next release version.

I'd prefer the latter, however, a new experimental version would be needed as well, since TB78.6.1 fixes a critical security flaw.

Tested it, but works only partially for me. At my company, we use addresses like <Firstname.Lastname@company.example.com> by convention. The alias rule to map "@company.example.com" applies, as far as the recipient list is concerned. It lists the recipient "Firstname.Lastname@company.example.com" with the status "a -> b" as expected. When I try to send the email, I get an unspecific error. The developer console is not helpful in this case, too, as it only reports that the encryption failed without any details.

It works fine if I don't use capital letters in the local part, though. While our convention is to use <Firstname.Lastname@company.example.com>, our mailserver is case-insensitive (as usual), and mails addressed to <firstname.lastname@company.example.com> arrive as well, and applying the alias works perfectly in this case.

The problem in comment 65 sounds a lot like bug 1657390. Internally, TB converts all mail addresses to lower-case. Therefore, the comparison to "Firstname.Lastname@company.example.com" coming from the alias config file fails.
Maybe when parsing the JSON file, TB should do a .toLowerCase() to have consistent data.

Indeed it looks very similar. Note that my JSON file does only contain "@company.example.com", so no uppercase letters in that JSON file that could be affected by .toLowerCase(). The alias map in the encryption JSON object (dumped to the console) contains the recipient address with the capitalized local part, though, as does the "to" member in that JSON object:

{
  "sender": "0x0000000000000000",
  "sign": false,
  "signatureHash": "",
  "sigTypeClear": false,
  "sigTypeDetached": false,
  "encrypt": true,
  "encryptToSender": true,
  "armor": true,
  "senderKeyIsExternal": false,
  "to": [
    "<Firstname.Lastname@company.example.com>"
  ],
  "bcc": [],
  "aliasKeys": {
    "Firstname.Lastname@company.example.com": [ "111122223333444455556666777788889999AAAA" ]
  }
}
Attachment #9191902 - Attachment is obsolete: true

TB 78.7.0 is out, including some important security fixes.
Once again, will there be a new experimental build with the alias functionality on top of TB 78.7.0?

While I understand there's nothing guaranteed with the experimental build, the lack of consistent updates for it, and the uncertainty whether there will be updates at all is a no go. I reverted to the release version for normal use, and will have to fall back to TB68 for group encryption. I don't think I will try an experimental version again under these uncertain terms.
I can only hope the alias functionality will land in the release version soon.

See Also: → 1684276
Attachment #9191902 - Attachment description: Bug 1644085 - Code preparations, partial merging from c-c, necessary for a single feature patch. r=mkmelin → Bug 1644085 - Code preparations for esr78, partial merging from c-c, necessary for a single feature patch. r=mkmelin

Encryption messages to lists work. This would be perfect for me if integrated into the release version.

For context and past comments on the following detail, please search this page for "failure".

During code review, Magnus said, in his opinion failures shouldn't be allowed at all. He suggests, if an alias rule maps to a key that is unusable, then it should always result in a failure to send.

In other words, Magnus suggests we remove the ignore_failures flag from the alias definition, and behave as ignore_failures=false.

Does anyone disagree and can present a strong argument why the ignore_failures flag MUST be provided in the initial implementation?

Magnus made another suggestion during code review.

He suggests, the presence of an alias rule for a specific email address should override a domain alias.

In other words, if two rule exists for bob@example.com and @example.com, but no rule exists for alice@example.com, then

  • an email to bob@example.com is encrypted to the key(s) defined for bob, only
  • an email to alice@example.com is encrypted using the domain key(s) for @example.com

(In my previous explanations, I suggested the email to bob@example.com would be encrypted to both aliases, email alias AND domain alias.)

Can everyone accept this simplification?

Generally, such a failure is just an indication that the user's keystore is not up to date or the key is misconfigured, and so the user will be strongly encouraged to synchronize their keystore with the mailing list. I think we can live without such a flag, provided that the wrong keys can be identified by the user.

I think the simplification for the domain keys is fine.

I think the simplification regarding domain keys is actually more flexible:

  • If you want to encrypt an email to Bob with both Bob's key andthe domain key, you could add both keys to Bob's rule, no?
  • If you don't want to include the domain key but still want the domain rule (for other recipients) this wasn't possible before.
Attachment #9189756 - Attachment description: Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin,PatrickBrunschwig → Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin
Attached patch merged for esr78 (obsolete) — — Splinter Review

In phabricator is the patch for comm-central.

This attached file is a merged version for esr78.

Attachment #9169818 - Attachment is obsolete: true
Attachment #9170892 - Attachment is obsolete: true
Attachment #9189756 - Attachment is obsolete: true
Attachment #9189820 - Attachment is obsolete: true
Attachment #9193371 - Attachment is obsolete: true

I'll link a new experimental build (esr78 branch) today.
Apologies for the delay, my body needed a bugfix.

I tested the new binary within Debian 10. Encryption seems to work as expected, thanks for working on this!

Unfortunately, when I want to check the "Message Security" info of the message sent by clicking on the OpenPGP Button on the right side of the message header, as the window is (of course) too small to show all recipients and I can't scroll down to see the other recipients (see attached screenshot). It would be great to have the possibility to see all recipients the message was encrypted to.

Apart from this I'm happy with the solution.

@dnk089

Interesting... I am using it on Arch with i3 and got a scroll bar. Seems to be inconsistent.

@Clemens Hanel: Interesting, too. I rechecked by sending mails directly to more then 6 Recipients (without using Aliases) and it's the same. So the problem is not connected to this bug. I'll try to find a corresponding bug report ...

I think there is no bug for that issue yet. You commented in bug 1679002, but that's a different window.

The issue from comment 78 and following should be reported as a new bug, please CC :aleca on the new bug, who is likely to work on a fix.

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

I think there is no bug for that issue yet. You commented in bug 1679002, but that's a different window.

The issue from comment 78 and following should be reported as a new bug, please CC :aleca on the new bug, who is likely to work on a fix.

Thanks, see https://bugzilla.mozilla.org/show_bug.cgi?id=1692497

Attachment #9189756 - Attachment is obsolete: false

Following the diskussion in Phabricator (https://phabricator.services.mozilla.com/D97973), pls note that adding an alias-encrypted mailing list in BCC would be really helpfull. Sometimes it is necessary to e.g. respond to an email and giving a signal to an alias-encrypted internal list, that I take care about this mail. Therefore it would be great to simply add the list to BCC. Otherwise I would have to forward the just sent mail to the list afterwards.

BTW: I am not sure if an email would disclose the recipient's keys to TO-address, when using BCC with (alias) pgp key(s) - enigmail or OpenPGP.

It would. Bcc with encryption is not let through at the moment (due to that).

Thx. Then its ok to keep it like that (a hint would be wonderfull).

Attachment #9191902 - Attachment is obsolete: false

I originally wanted to have a single patch that applies on both comm-central and comm-esr78.
That was the purpose of the small phabricator patch D99062, which Magnus had already r+'ed.

In the meantime both branches have diverted in some details. It's necessary to have a manually merged patch for esr78.
I'll add the contents of D99062 to future patches for esr78.

Attachment #9191902 - Attachment is obsolete: true
Attached patch 1644085-20210223-esr78.patch (obsolete) — — Splinter Review

merged for esr78

Attachment #9202635 - Attachment is obsolete: true

Is there any date known/expected when GPG aliases will be included in the official release channel version? Its not in the latest 78.8.0.

I also looked at the changelog available for the beta channel (e.g. https://www.thunderbird.net/en-US/thunderbird/86.0beta/releasenotes/ and older) but didn't find anything regarding GPG aliases in the more recent releases. So it seems this feature hasn't yet made it into beta? I also followed subject encryption, and it took about a month to move this feature from beta (v83, end of October 2020) to the official release (v78.5.1, beginning of December 2020).

So are there any expectations when we could see this feature in a beta release?

Due to this missing feature, we are all still with version v68.x. We don't want to implement alternatives to gpg-aliases/per-recipient rules, and then switch back again whenever GPG-alias functionality is released in the official channel. It would only confuse our colleagues, and mean a lot of work for us explaining those changes.

Ihe latest v68 has been released in October 2020, and I would expect it is EOL since some months now, so naturally we want to know whether we should wait for GPG aliases making it into release channel soon, or we have to think of per-recipient alternatives.

The patch is pretty far, so I'd expect it by 78.9.0 in a month.

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

Below are download links to an experimental 78.x build that contains the latest patch.
(the build also contains patches for bug 1681887, bug 1673239 and bug 1692909)

The new try build does not work for me. I do use an offline primary OpenPGP key, hence the private key is in the GnuPG keyring, and only the public key is in the TB78 OpenPGP Key Manager.
When attempting to send an encrypted message I get this error:
"Unable to send the message, because there is a problem with your personal key. You do not seem to have the secret key for <my secret key> on your keyring; you cannot use the key for signing."

OS is OpenSUSE Linux. As per the Error Console gpgme isn't the problem:
Successfully loaded optional OpenPGP library libgpgme.so.11 from system's standard library locations

The error remains the same when turning off signing. It doesn't make any difference whether an actual alias is used or not. So this looks more like a generic problem. There was no such problem with the previous try build based on TB78.7.1. There is no problem with the TB78.8.0 release version either.

Not directly related, I also adjusted the syntax of the json file as per the examples at https://phabricator.services.mozilla.com/D97973#change-qmH8rDI6Zn2w.
Is that the right place to look at? It isn't obvious to me based on the terse explanation in comment #90.
Thanks.

Christian, thanks for the feedback. What was the last experimental build that worked for you with your setup?

The one in comment #77, a.k.a. Daily 78.7.2.

(In reply to Christian Riechers from comment #93)

The new try build does not work for me. I do use an offline primary OpenPGP key, hence the private key is in the GnuPG keyring, and only the public key is in the TB78 OpenPGP Key Manager.
When attempting to send an encrypted message I get this error:
"Unable to send the message, because there is a problem with your personal key. You do not seem to have the secret key for <my secret key> on your keyring; you cannot use the key for signing."

Christian, do you use encrypted but unsigned email? If so, you should be aware that it’s a bad idea: https://k9mail.app/2017/01/30/OpenPGP-Considerations-Part-II.html Several software don’t support such a feature and I’m surprised TB does.

I found the cause for the regression reported by Christian in comment 93.
It was a mistake in a regular expression.
Phabricator has already been updated.

I'll soon upload a new 78 experimental build.

Note that the most recent build had changed the json syntax to use "id" for both fingerprints and key IDs. Magnus has requested that I change that, so the json file needs to specify fingerprints with "fpr" and key IDs with "id".

Attached patch 1644085-20210224-esr78.patch (obsolete) — — Splinter Review
Attachment #9204863 - Attachment is obsolete: true

Is "fpr" a common abbreviation? Why not use "fingerprint"?

(In reply to kg from comment #99)

Is "fpr" a common abbreviation? Why not use "fingerprint"?

Maybe not common, but it's less typing. It will be documented.

Attachment #9205357 - Attachment is obsolete: true

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

(In reply to kg from comment #99)

Is "fpr" a common abbreviation? Why not use "fingerprint"?

Maybe not common, but it's less typing. It will be documented.

after your comment, Magnus actually requested to change it to "fingerprint... so, format will change again.

Attachment #9205184 - Attachment is obsolete: true

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/8ce54a39c29a
Support recipient aliases for OpenPGP encryption. r=mkmelin

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
status-thunderbird87: --- → affected
status-thunderbird_esr78: --- → affected
tracking-thunderbird87: --- → +
tracking-thunderbird_esr78: --- → +
Target Milestone: --- → 88 Branch

Thank you for your efforts. :-) We really appreciate it.

Yes, thanks so much, we are really waiting for this feature.

To get a sense regarding the timetable: target Milestone branch 88 would in practice mean that within ~1 month its in Beta (as end of Feb it might almost mean 87beta?) and in another month in release, right? Just to double-check regarding the comment by Magnus https://bugzilla.mozilla.org/show_bug.cgi?id=1644085#c92

We usually do more than one beta per beta cycle. Likely we can put it in 87.0b2 next week, and if all goes well into 78.9 March 23.

Hi, I also consider this feature as esential! I just tried it (using 78.8.0 daily from, above link) on a mac, but I fail... I created a json file as described in https://bug1644085.bmoattachments.org/attachment.cgi?id=9193371 (did the format change meanwhile? I read about "fpr" insetad of "id"?). Weird is, no matter if I store and reference the json as full path, as file in the profile directory itself, or even with a completely wrong path in the config: I do not get any error message at start, and whenever I try to send ANY mail that I set to "Require Encryption" with "OpenPGP" Encryption Technology - it is just, WITHOUT ANY WARNING (!) - sent unencrypted. Seriously, that's the WORST possible behaviour... never ever mail something without encryption that has the encryption flag set without a warning, this can lead to a disaster. But besides this, what went wrong?

PS: I see that the json format obviously changed (but did not find where the " test files in the phabricator attachment for examples" are located?). Nevertheless, I think mails marked as requiring encryption should never leave unencrypted, even if the json format might contain syntax errors.

(In reply to Andreas Greulich from comment #110)

PS: I see that the json format obviously changed (but did not find where the " test files in the phabricator attachment for examples" are located?). Nevertheless, I think mails marked as requiring encryption should never leave unencrypted, even if the json format might contain syntax errors.

OK I found the samples (https://phabricator.services.mozilla.com/D97973#change-qmH8rDI6Zn2w I reckon), and with the correct syntax, it works. Nevertheless - in case of a wrong syntax or the old format, make sure mails that should be encrypted never leave TB in clear.

There's no belts and suspenders: You're responsible for having the right syntax (errors are logged). If encryption required is set, Thunderbird will require a key, it won't require that you have the right syntax. There is no "old" format, what landed is the format we have.

Set the mail.openpgp.alias_rules_file pref to openpgp-alias-rules.json - and create a JSON file named like openpgp-alias-rules.json

  • put it in the Thunderbird profile folder or
  • a file:// url pointing to the file

The openpgp-alias-rules.json file content should look something like this:

{
  "description": "Thunderbird OpenPGP Alias Rules",
  "rules": [
    {
      "domain": "domain1.example.com",
      "keys": [
        {
          "description": "Catch-all for domain1.example.com",
          "fingerprint": "EB85BB5FA33A75E15E944E63F231550C4F47E38E"
        }
      ]
    },
    {
      "domain": "domain2.example.com",
      "keys": [
        {
          "description": "domain2.example.com folks",
          "fingerprint": "D1A66E1A23B182C9980F788CFBFCC82A015E7330"
        }
      ]
    },
    {
      "email": "list@domain1.example.com",
      "keys": [
        {
          "description": "John",
          "fingerprint": "D1A66E1A23B182C9980F788CFBFCC82A015E7330"
        },
        {
          "description": "Eve",
          "id": "F231550C4F47E38E"
        }
      ]
    }
  ]
}

Yes, thank you, I found that meanwhile - I still think the syntax should be updated on https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases as this is the most official doc of it except you read through the whole thread here (and this page states "Create a new text file, as described here: https://bug1644085.bmoattachments.org/attachment.cgi?id=9193371" where another json format is described; this is the one I intrerpreted as "old" format).

But my point is another one (and trivial to solve I think): If you have such a file correctly configured, but change e.g. the path slightly (insert an "_" or whatever), then - after TB restart - write a mail to somebody of whom you DO have an exact PGP key (so no aliases required), mark "Require Encryption" and set "Encryption Technology" to "OpenPGP", and try to send it - the mail WILL be sent, but UNENCRYPTED! This is something that I really warn you MUST be fixed before making it public, or disasters will occur. The problem is not about error messages or not, the problem is that a mail that you marked with "Require Encryption" is sent out in clear without any warning. As soon as the openpgp-alias-rules.json entry is cleared again, all works as expected and the mail is encrypted (again after restarting TB).

I think what happens is that if anything goes wrong - be it just that the json file is not found, or one little keyword in it mistyped, maybe a comma in the json that should not be there - PGP is turned off completely, but the GUI still pretends it to be active. The problem really is not that aliases would nto work, but that the complete PGP module seems to become inactive. So the user does everything he would usually do, nothing is greyed out in the GUI for instance, but the mail is sent out in clear. The only hint I see you get is, if you click on "Security" before actually sending it, you see that no PGP key appears as available. But who makes this check? As said, this must not happen in a productive version. I'm aware that this is still test phase, which is fine, just please do not forget to clean that problem up before putting it into the actual release.

As a sum up: whenever the user has "Require Encryption" set and was able to set it, the mail must never be sent out in clear without an additional warning.

br, Andy

Thanks again. I really like the "description" line in the alias definition, this makes it easier to add/remove key ids or fingerprints.

I agree with Andy that mails should never pretend to be sent encrypted when they are not, although I could imagine that this will make development more complicated.

Depends on: 1695590

Filed bug 1695590 about not sending when there were problems with the alias file.

I can reproduce, and I fully agree, this is a serious bug. We should never send a message unencrypted, if the settings require encryption.

I had anticipated in bug 1648019 that this may happen potentially. Now we have the first time this happens, and I think it's a good opportunity to fix both the specific regression, and also a general protection mechanism as suggested in bug 1648019.

I've updated the documentation page at
https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

Since this is a huge email list, could you also briefly explain there how to fill your file. Why does John have a fingerprint and Eve an ID ? Do they share the same email ?

And why is there an ID for the email but not for the domains?

You can do the mapping either by id OR fingerprint, your choice.
If you have a huge list (not sure what format?) you probably want to do a script to output what you need. It's a JSON file, all white space optional. The descriptions as well.

Comment on attachment 9189756 [details]
Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: feature requested by many users
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): low, shouldn't affect users not yet using this feature

Attachment #9189756 - Flags: approval-comm-esr78?

Note, when uplifting, it's important to also take bug 1695590

I'm adjusting to subject of the bug, to clarify we fixed only a subset of the suggestion.

We support multiparty encryption and recipient aliases - but we don't yet support the full feature set of per-recipient rules in Enigmail (which e.g. offered the ability to enable/disable encryption based on recipient.).

Summary: Support automatic multiparty encryption, similar to groups in GnuPG or Per-Recipient Rules in Enigmail → Support automatic multiparty encryption, similar to groups in GnuPG
Summary: Support automatic multiparty encryption, similar to groups in GnuPG → Support automatic multiparty encryption, similar to groups in GnuPG (recipient key aliases for email or domain)

Comment on attachment 9189756 [details]
Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin

sorry, above approval request was intended for beta - I think we should get some beta testing, prior to uplifting to esr78

Attachment #9189756 - Flags: approval-comm-esr78? → approval-comm-beta?

Thanks, documentation is great now and I like the fingerprints can be documented as well!

I have found another bug, but I'm not sure what exactly lies behind it. I think it has to do with upper/lowercase writing of E-Mail. I noticed that the rules seem to fail if the mail used is written in uppercase and in the rule in lowercase. But it also fails if it is written in uppercase in the rule. Another source of failure is when a mail address in an actual mail is written in the "name <name@xxx.com>" format.

Here a series of tests, using a sanitized naming list mail address. It usually appears as:

LIST1 <LIST1@LISTSERV.XXX.YY>

In the keyset rule I use (together with a bunch of fingerprints):

"domain": "listserv.xx.yy"

In this case, when composing a mail with encryption on clicking on the "Security" button, I get

"list1@listserv.xx.yy a -> b"

which seems to tell a matching key was found; but when I try to send it, it tells (note the uppercase address)

"Unable to send this message with end-to-end encryption, because there are problems with the keys of the following recipients: LIST1@LISTSERV.XXX.YY"

Of course I have no way to see what the error was (or do I?). Now, when I change the "domain": entry above to uppercase as well, the "Security" button already tells me there's no match ("no key available" instead of "a -> b")

So I change the "domain" line back to lowerwase, but change the recipient mail to

LIST1 <LIST1@listserv.xx.yy>

The behaviour changes once more, now I get a simple "Sending of the message failed.".

Changing the recipient to "LIST1@listserv.xx.yy" has the same effect.

Only when I finally change it to "list1@listserv.xx.yy" it works as expected.

As mailing lists often produce uppercase mail addresses with <...> terms, to which you should be able to reply, this is a bug that I think must be fixed.

br, Andy

PS: I made my tests with the version of comment 104 7 days ago. I don't think there's a newer one available.

Comment on attachment 9189756 [details]
Bug 1644085 - Support recipient aliases for OpenPGP encryption. r=mkmelin

[Triage Comment]
Approved for beta

Attachment #9189756 - Flags: approval-comm-beta? → approval-comm-beta+

Thank you. Yes, I confirm, it doesn't work if anything uses uppercase. I'm working on a follow-up patch with more tests.

Blocks: 1697239

I've implemented fixes and more error checking in bug 1697239.

Here is a new experimental build, that is based on latest 78.8.1, with this patch, and bug 1697239 and bug 1695590.

ah sorry, build is not yet ready, I'll submit another comment in a few hours

Regarding beta: The fix for bug 1697239 has not yet been reviewed. But I think it still makes sense to already land the approved patches into beta, as it will allow testing for (potential) side effects.

Andreas, could you please test, and provide feedback in bug 1697239 ?

I did a short test with linux64 version from Comment 132:

1.: Mail to "NAME@DOMAIN.NET", alias definition with "name@domain.net"
2.: Mail to "name@domain.net", alias definition with "NAME@DOMAIN.NET"
3.: Mail to "name@domain.net", alias definition with "NAME@domain.net"

In all 3 cases I get the following error message:
"Unable to send this message with end-to-end encryption, because there are problems with the keys of the following recipients: name@domain.net", followed by "OpenPGP Message Security" Infobox, telling "Status: Alias Problem"

So in every case the same error message when To-address does not match address definition in the alias file.

(In reply to dnk089 from comment #134)

1.: Mail to "NAME@DOMAIN.NET", alias definition with "name@domain.net"

I tried this, too, with the above linux64 build. It works for me. Can you please look at the error console for information? Note that the failure is expected, if there is an error in your JSON file, or if you don't have the key available. The error console should tell you what's wrong.

Flags: needinfo?(dnk089)

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

I tried this, too, with the above linux64 build. It works for me. Can you please look at the error console for information? Note that the failure is expected, if there is an error in your JSON file, or if you don't have the key available. The error console should tell you what's wrong.

Sorry, had a key included in aliases that is invalid since 3 days :-)
The results after removing that invalid key:
1.: Mail to "NAME@DOMAIN.NET", alias definition with "name@domain.net": Works, Status : a->b
2.: Mail to "name@domain.net", alias definition with "NAME@DOMAIN.NET": Fails, Status: no key available
3.: Mail to "name@domain.net", alias definition with "NAME@domain.net". Fails, Status: no key available

Flags: needinfo?(dnk089)

(In reply to dnk089 from comment #136)

2.: Mail to "name@domain.net", alias definition with "NAME@DOMAIN.NET": Fails, Status: no key available
3.: Mail to "name@domain.net", alias definition with "NAME@domain.net". Fails, Status: no key available

This works for me.
What does the error console say for those, and please share the JSON rule you use.

I've added the three examples from 134 to the automated tests in bug 1697239, and they pass. It seems likely that dnk89 has had some kind of mistake locally when testing.

Confirm. Issue with 2. and 3. was connected with editing alias file without restarting thunderbird. After restarting thunderbird 2. and 3. passed. Sorry for delayed answer.

Thanks a lot, much sppreciated, everything seems to work now as expected :+1: Very cool that it is even possible to modify the json file without having to restart TB.

One small thing that I could not make work (on MacOS) is to read the json file from any path in my homedirectory, no matter if I gave the absolute path ('/Users/../xxx.json'), used , \, or / as separators, or '~/'. This is no big issue for me as I'm fine putting it in the profile directory (actually I use a hard link to my Documents directory), but I wanted to mention it. Maybe I also missed the rigth syntax.

A few things (no bugs) that would be nice to have: allow space separators in key fingerprints, so they can easily be copy/pasted from key manager (currently one must manually remove spaces beforehand), allow more than one domain or E-mail address per recipient list (in case the same list should be used for different recipients) or some other way to avoid repeating key lists in such cases (like one entry referencing another), and more generic rules to determine the key list to apply, like keywords/patterns in the subject (useful for mailing lists where the domain is shared between different lists). But all these things are not really relevant.

@Andreas Greulich: If the JSON is outside the TB profile directory the file path must be given as a URI: file:///User/blabla/my_alias.json

Comment on attachment 9205359 [details] [diff] [review]
1644085-0225a-esr78.patch

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: missing feature which many users are waiting for
Testing completed (on c-c, etc.): c-c and comm-beta, all existing and new tests pass. Since follow-ups bug 1695590 and bug 1697239 were addressed, no further problems have been reported with the 78.x test build.
Risk to taking this patch (and alternatives if risky): medium, because the patch is big and touches existing OpenPGP workflow.

Attachment #9205359 - Flags: approval-comm-esr78?

So why did this not land in 78.9.0? (Or did it? This Bugzilla is a little confusing for me.)

The release driver has asked for more testing. We currently intend to release a 78.9.1 in the next 1-2 weeks.

I'll create a new experimental build today, based on 78.9.0

Thank you so much.

FTR: I did a few tests and does work for my use case (a single key for a coporate domain).

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

linux64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ei7_S14jRRGgFt08B4Ibyg/runs/0/artifacts/public/build/target.tar.bz2

Tested on debian buster: sending mail to list with defined recipient aliases works fine, even with lowercase / UPPERCASE mix. Thanks a lot!

Comment on attachment 9205359 [details] [diff] [review]
1644085-0225a-esr78.patch

[Triage Comment]
Approved for esr78

Attachment #9205359 - Flags: approval-comm-esr78? → approval-comm-esr78+

Dear all,
thanks again so much for this implementation! if anybody uses this alias file in an organization (of with a group of people, and the aliases changes up, and then) I've created a simple addon which downloads the alias json file from a server: https://addons.thunderbird.net/en-US/thunderbird/addon/openpgp-alias-updater/

the openpgp alias parameter must be set as explained here: https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

See Also: → 1691235

This is a great fix. Is there any timeline on when this fix will be added to the core functionality of Thunderbird?

This ticket has already been merged to release and is available since 78.9.1.

it seems not to work with thunderbirds built-in address book lists.

  1. I have an address book list that appears as list <listname> in the addressbar

  2. without alias-list, it returns the error, that there is no gpgkey available for listname

  3. I created an alias-list according to: https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases

    {
    "email": "listname",
    "keys": [
    {
    "description": "foo",
    "fingerprint": "XXXXFAA6E562943FB4B145005B7D716CF79F2378"
    },
    {
    "description": "bar",
    "id": "XXXXA1C41D5F97CEC212B4BC4F80A27FC8CD1E18"
    }
    ...

  4. Now the Status keeps forever in "Creating mail message..." and a Send Message Error "Sending of the message failed" appears.

  5. When I click ok on the Send Message Error, the Sending Messege popup closes also.

Correct, it has to be a real email.

See Also: → 1752522

In the wiki page, the major doc revision https://wiki.mozilla.org/index.php?title=Thunderbird:OpenPGP:Aliases&diff=prev&oldid=1234239 has lost the critical information about how to configure TB to use the file, i.e. as said somewhere above:

  • Open the advanced config editor.
  • Set the mail.openpgp.alias_rules_file pref to a filename, e.g. openpgp-alias-rules.json - and create a JSON file with this name.
  • Place the file in the Thunderbird profile folder or
  • a file:// url pointing to the file
  • Restart Thunderbird.

pyxis24, I cannot confirm, looking at the most recent revision of https://wiki.mozilla.org/Thunderbird:OpenPGP:Aliases
I still see the following sentence:
"To configure and enable an alias file, open preferences, config editor. Set preference mail.openpgp.alias_rules_file to an empty string (default) to disable the use of aliases. To use a file that you have manually copied to the profile directory, enter its filename without a path (e.g. openpgp_alias_to_keys.json, no / or \ characters are allowed). To use a file that is stored elsewhere on your system, you may enter a full file:// URL. "

Indeed I must have missed somehow the 'config editor' part while reading. Sorry.
Partially that was caused by a lack of structure in these lines, maybe that could be improved as suggested above.
Seems creating a wiki account is a longer process, otherwise I would have done that already.

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

(In reply to vv01f from comment #45)

why not letting users decide on signatures on a per-receipient basis?

signature status -> later

The details of a signature status would have to explain that an alias rule was involved.

Is there any news/timetable on this? I would like to also accept signatures signed with an alias key.

Flags: needinfo?(kaie)

(In reply to jigozkgvc from comment #161)

The details of a signature status would have to explain that an alias rule was involved.

Is there any news/timetable on this? I would like to also accept signatures signed with an alias key.

Aliases and signature status is tracked in bug 1752522. No recent news.

Flags: needinfo?(kaie)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: