This page lists high level completion status for various work items related to Thunderbird's OpenPGP integration.
This page might be out of date! Even if a feature is marked as done, it might be an initial implementation, only, that needs further improvement. The ToDo list is incomplete, it simply attempts to give an overview what's on our current radar. More items will be added as development continues. See also the Bugzilla Query for open bugs.
Last updated: 2020-05-18 for TB 77 Beta 3
- use better defaults for new key generation (currently for testing, 1 month expiry)
- shouldn't notify the user about attached key if the same key has already been imported
- interactive assistance to help the user configure OpenPGP
- migration of Enigmail settings
- modifying the expiration date of a key
- notify the user if their key will expire in the next months
- sending an INLINE cleartext signed message without attachments (we don't intend to support sending other kinds of inline OpenPGP messages)
- sign (certify) someone else's key if a key is marked as verified
- Should strip keys (to minimize their size) when sending the user's own public key as an attachment
- allow advanced users to use a personal key that's used on a gnupg smartcard (GPGME API) and use it for signing a message (nevertheless, encryption will be done using RNP)
- ambiguity warning when more than one recipient key is available (e.g. unexpected / changed key)
- automatic scanning of received emails for potential correspondent keys, expiration changes and revocations
- an option to disable subject encryption
- backup of secret keys, reveal passphrase for keyring?
- remembering encryption/signature configuration in a draft message
- performing secret key generation in a nicer way (currently the UI will block while the key generation is working)
- an optional mode to automatically encrypt "if possible" without requiring the user to manually enable it for the individual message (if the user has accepted and valid keys for all receipients of a message)
- automated unit tests for the Thunderbird integration
- actions for message filtering
- automatic detection if a correspondent’s key has been already been signed (certified) by one of the user’s secret keys (in this case, we should automatically give it acceptance status “verified”)
- reject messages with missing MDC
- better handling of importing keys, give feedback on failure
- give feedback if key discovery got not result
- fix linux dependencies, support older distributions
- allow distributing sender's key with the autocrypt header mechanism
- potentially consume and send gossip information
- test if we're vulnerable to known security attacks
- internal key store in TB profile directory (not to be shared)
- secret keys protected with an automatic passphrase, optionally protected using TB's master password
- manually generating a new secret key (which automatically saves a revocation certificate and stores it in the user's profile directory)
- manually importing secret keys from a backup file (e.g. one created by gnupg and exported using gpg --armor --export-secret-keys). The key needs to be unlocked at import time, and will be protected with a random password as described above
- manually importing a public key from a file, or from an URL, or from an email attachment
- end-to-end encryption preferences for an email account that covers both OpenPGP and S/MIME
- sending of OpenPGP messages is configured by selecting the user's preferred OpenPGP key in account preferences (an appropriate key, with a matching email address, must have been manually imported already, or already have been generated inside TB)
- message composition: selection of the encryption technology to be used (either S/MIME or OpenPGP) while composing a message
- manually enabling encryption or digital signature while composing a message, and attaching your own public key
- decryption and verification of received messages, including status icons for the encryption status and/or digital signature status
- detailed message security info for received messages, open by clicking on status icon
- a mechanism that allows the user to manually define the validity of a public key. We're (at least temporarily) using the term "Acceptance" for that, to indicate that it's a user decision, whether a key is accepted or not. Before TB will accept a correspondent's public key, it's necessary to use the "OpenPGP Key Manager", find the appropriate key and open the key details (either double-click, or select menu View / Key Properties, or press CTRL-I). In order to allow that a key is used for sending encrypted messages, one of the "Yes" choices needs to be selected. The choice is remembered inside TB's storage.
- The signature status shown for a received message depends on the validity setting the user has made.
- The key details view shows the full list of all certifications on the key, even those from keys which are unavailable (Enigmail filtered the list to only show certifications from available keys).
- The key details view shows the structure of the key
- send encrypted subject (on by default)
- we automatically enable signing, if the user manually enables the encryption flag for an email (this automatism could be made configurable later)
- we automatically attach the user's own public key, if signing is enabled
- discoverable sender key that's attached using the autocrypt header mechanism, support to manual import of email
- if unavailable, allow the user to start an Internet search (WKD and keys.openpgp.org) for the key a correspondent used to sign their message (necessary for verifying a signature)
- allow the user to start an Internet search for a correspondents key (WKD and keys.openpgp.org), using a popop menu command on from/to/cc entries when reading any email.
- keyserver / WKD retrieval from within email composer
- assistance to resolve missing recipient keys when composing an email
- initial preparation for supporting GnuPG smartcards for secret key operations (decryption works, need to enable pref mail.openpgp.allow_external_gnupg)
| end of ToDo
|| end of Done
| Not Planned
- we don't intend to enable the encryption feature automatically, user needs to discover the feature and enable it on their own (by configuring their personal key)
- we don't plan to automatically accept keys that we receive, regardless of mechanism. Users must accept keys of other people before they are used, to encourage them to verify their correctness.
| end of Not Planned