[Mailman-Developers] [GSoC] Encrypted mailing lists - update v11

[Jan Jancar]

Hi all!

Another week, another update.

https://neuromancer.sk/article/15

====================
GSoC 2017 - Progress
====================

This week was tough but productive. Temperatures spiking to 34°C in my
hometown have a really bad effect on my daily productivity.


Setup instance with PGP plugin
------------------------------

Finally got a complete mailman [instance](https://mail.neuromancer.sk)
setup and running with J08nY/mailman/plugin + J08nY/mailman-pgp/master
and J08nY/Postorius/plugin + J08nY/mailmanclient/plugin +
mailman/HyperKitty/master + mailman/django-mailman3/master. The `plugin`
branches merge MR branches that introduce the plugin infrastructure for
that particular Mailman component. For Mailman Core, the `plugin` branch
merges the `pluggable-components`, `pluggable-workflows` and
`list-style-descriptions` branches.

The `pluggable-components` one introduces the concept of a `plugin` to
Mailman Core and replaces the `(pre|post)_hooks` and is essential to let
site admins easily add plugins to Mailman Core by simply installing them
to the same environment as Mailman Core and some simple configuration to
enable. `pluggable-workflows` splits the subscription/unsubscription
monolithic workflows into composable workflows, that are also pluggable
by a plugin and set per-list. `list-style-descriptions` are exposed via
the REST api and Postorius uses them for displaying list style selection.

I even successfully created a PGP enabled discussion list through
Postorius. Subscribed to it by sending the subscription request,
confirming it, replying to  the `key set <token>` challenge with key
attached, replying to the `key confirm <token>` with the challenge body
signed by the key being set. This would of course be followed by the
moderator verifying the supplied key in any real application of PGP
enabled lists, which is also supported.

The instance runs on a Raspberry Pi with 512MB RAM along with my
web-server, mail-server and several other services, so don't expect
lightning fast performance, or it being up anyway, reserving the right
for any extended downtime ;).


Key revocation
--------------

Working on proper key revocation behavior from the PGP plugin took much
of my week as getting this right is pretty hard and the OpenPGP
revocation mechanism is quite complex. The usual workflow for just an
ordinary key change was already presented in one of my previous posts.
However if the user needs to revoke a key with a revocation signature,
we cannot use the old key to perform the key change challenge. Also, the
key revocation can be only partial, as in a subkey being revoked, and
the key can still be used for encryption and signing, then it's usable
for the PGP plugin and nothing needs to be done. This also gets more
complex as when we allow a user to change his key without moderator
approval, only with the challenge (which makes the user sign a
challenge/statement signifying they are changing their key to the new
one, by the old key). Then if the user revokes his former key using a
reason for revocation that invalidates all signatures by that key(even
former ones), we cannot trust the users current key, as the old one
could have been compromised and used to set the new one.

For now, giving a mechanism for users to provide a revocation
certificate that is verified merged with the key is implemented. If the
revocation certificate revoked the key or a subkey/uid that makes the
key not usable by the PGP plugin (the key can no longer be encrypted to
or can sign) then the users key is reset and he/she has to send and
confirm a new one with moderator approval necessary. That is almost
completely implemented as it's almost the same as the subscription
challenge.


More PGPy work
--------------

Necessary to make it usable, as for example, not having support for
partial length headers would break handling of most messages encrypted
with GPG as it likes to create plenty of packets with partial lengths.
However, now I think that my development branch of PGPy is feature
complete enough to support an instance of Mailman with the PGP plugin
running.

Trello board
------------

Setup a Trello board to better track the issues that I came up and keep
my head sane (private board):
https://neuromancer.sk/static/mailman_pgp_trello.png

Next up
=======

Web UI integration
------------------

The original proposal proposed adding support for PGP enabled lists to
Postorius and HyperKitty directly, now when mailman-pgp is dynamically
enabled in Mailman Core a similar approach needs to be taken with the
Postorius and HyperKitty integration.

Archiving
---------

Thinking of doing local archiving very similar to the prototype
archiver, encrypted by the list local-archive key. The remote archiving
capability is a much tougher nut to crack and depends a lot on how the
HyperKitty integration ends up looking.


Cheers,
-- 
Jan
______________________________________________________
   /\  # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D
  /__\  # https://neuromancer.sk
 /\  /\  # Eastern Seaboard Phishing Authority
/__\/__\  #

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170804/b2c63c35/attachment.sig>