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 /__\/__\ #