There should be a way to encrypt emails sent by MediaWiki. (See recent Facebook announcement of a similar feature.) The user should be able to provide a GPG public key and MediaWiki would encrypt the email with that key, and possibly sign it with some key that belongs to the operator, to prove that the email indeed originated from the wiki.
There are several features that could benefit:
- messages from other users via Special:Emailuser (probably the highest value)
- system notfications (for password reset links this provides some added security against a powerful opponent; for watchlist notifications it improves privacy)
- Echo notifications - not sure they are used for anything right now that's particularly private, but they might in the future. Also important for private wikis, especially if something like T90067 gets implemented, but page names might be considered private information as well.
MVP
- handle a single GPG key by providing a text box in user preferences where the user can paste their key
- provide basic instructions, probably by linking to something like (1) (2) (3)
- verify that the key is valid and not a private key
- add a checkbox to enable/disable encryption
- encrypt user->user mails and Echo mails
(Some further ideas that are not in scope for the MVP: expose the key via API, allow setting up a sitewide key and use that to sign, refactor email handling so there is an appropriately high-level hook that all mails got thtough (so we can encrypt non-Echo system mails), do the encryption on client side, do not double-encrypt already encrypted messages, send a test email with a verification link and only enable if the user could click on it (Facebook does this, and it seems like a good idea to prevent accidents), detailed documentation about setting up email clients or using Mailvelope-style extensions, keyserver support, keybase.io integration.)
Implementation plan:
- figure out whether the PECL gnupg library is usable. The Debian package was last updated in 2013, but it's supposed to use GPGME which in turn is a wrapper that makes calls to the gpg executable, so the version of the PECL library should not matter that much. For Wikimedia it would need to be recompiled with HHVM though.
- create a standalone library (which can be reused by the extensions consuming the GPG keys) for one more level of wrapping, either around the PECL library or the command-line gpg tool directly. Unfortunately both of those require using a keyring. We probably don't want to leave around public keys (which might be secret) in /var/www/.gnupg/pubring.gpg of random machines; we also don't want to break other extensions using GPG by permanently changing the home directory. So we need to do something like: create temp dir -> set GNUPGHOME environment variable to temp dir -> run GPG commands -> reset GNUPGHOME and delete temp dir (use a scoped callback or something similar to make sure this happens). This kind of sucks but should be doable.
- create Extension:GPGMail (name bikeshedding welcome)
- add the textarea and the checkbox to user preferences
- on save, call gnupg_import + gnupg-keyinfo to verify the key (the second might not be necessary)
- add the User objects of the sender and the target user as extra parameters to the EmailUser and EmailUserCC hooks, which are right now too low-level to be of any use
- add a similar hook to Echo; maybe in EchoNotificationController::formatNotification
- use the hooks and encrypt the mails.
(Ended up creating a new pair of hooks instead that affect every outgoing email.)
Status
Current version is suitable as MVP for small wikis but not for Wikimedia as there are multiple problems with storing the key in user options:
- they are verified every time they are loaded, but key verification is expensive and should only be done on change
- they are included into every page and a typical key is around 1K
- management interface is poor (e.g. should display key metadata)