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

[Jan Jancar]

Hi all!

Another week, another project update.

https://neuromancer.sk/article/13

====================
Post title goes here
====================

Signature hash tracking
-----------------------

It would be relatively easy to replay a signed message to a mailing list
by a user as no kind of challenge-response is done on posting.

While signature replay checking is usually done on the end users point
with against his keyring and messages he has so far received and their
context, I think it is kind of expected of PGP enabled Mailman to also
do this as it relays the messages.

On a successful posting to a PGP enabled mailing list (`AcceptedEvent`
to be precise), the message is searched for PGP signatures and their
digests and key fingerprints are added into the `sighash` table.

The signature rule then checks the digests from a posting against those
in the `sighash` table. If it finds it has previously accepted a message
with any of those hashes it takes the `duplicate_sig_action` which is
per-list configurable.

This of course means that if the `duplicate_sig_action` is not set to
`Action.defer`, which means the message gets rejected or dropped, that a
signature that was sent to a list cannot be sent again. Of course if a
user wants to send a signed message again, he can just resign it and
send it again, the hashes won't match. However sometimes it might be
useful to post the message as signed originally, for example to prove
something. However, I think it is worth it to keep this as a
configurable option. Maybe with another option disabling the collection
of signature hashes, for performance reasons.

Outgoing processing
-------------------

Since a the plugin needs to process the messages for outgoing encryption
on a per-recipient or per-chunk basis, it couldn't be implemented as a
Handler, I thought about implementing it as a custom OutgoingRunner but
that didn't work out either. However the `IMailTransportAgentDelivery`
interface is great for what the plugin needs to do. So there are two
custom PGP enabled delivery classes that get selected by a custom `[mta]
outgoing` callable, one for bulk delivery and other for individual delivery.

Documentation
-------------

I got the `pgpmailman-proposal` repository almost completely up to date
on changes to the plugin and my current proposed
Core/Client/Postorius/HyperKitty changes and MRs.

Next up
=======

More testing
------------

As I remembered to ignore coverage of tests it dropped to 88% and I
think it is currently in order to add more comprehensive tests for
features implemented that check the edge cases which currently remain.

Setup live development instance
-------------------------------

I believe I got pretty far into the development without having a proper
live development instance of Mailman Core + plugins and Postorius +
HyperKitty + Client, so I'm going to set that up now and test manually.
With time I might set this up as a public site/mailing list server, to
demonstrate the features of the PGP plugin.

Archivers
---------

Currently thinking about implementing two encrypted archivers, one
local, one remote. The local one would be similar to the prototype
archiver but store messages encrypted, TBD how. The remote one will send
the messages encrypted to a receiving archiver, the django-pgpmailman
instance running next to HyperKitty.

django-pgpmailman
-----------------

With most of the essential stuff in the core plugin done, the web ui
part of development can begin.


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/20170720/6ef2872e/attachment.sig>