Another week, another update.
==================== 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.
Finally got a complete mailman instance
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
branches merge MR branches that introduce the plugin infrastructure for
that particular Mailman component. For Mailman Core, the
pluggable-components one introduces the concept of a
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
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 ;).
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.
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.
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
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.
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.
Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__/__\ #