Hi Mailman Developers.
I am sending this mail as my proposal of encrypted mailing lists for GNU Mailman got accepted and I will be working on it this summer.
Sorry about not contacting you earlier, I had some issues where my site and mail server were down. If any of you tried to reach me and failed in the last ~week you can try next time on my backup mail email@example.com which should always work.
You can find the original (accepted) version of my proposal on: https://neuromancer.sk/static/mailman.pdf
# Status report so far into the Community bonding period:
encrypted mailing lists is really the only way to go forward here, as just pushing in what might end up being a rather niche feature into Mailman Core is not maintainable / wanted.
implemented without touching Mailman Core at all (as a plugin), what would require general changes and what might require specific changes (that means it needs a better solution).
can be easily implemented out-of-tree with only minor general changes to Mailman Core with the following exceptions that I'm currently solving:
* Making all commands require a confirmation (as subscribe / unsubscribe
has). This is necessary to stop replay attacks.
* Subscription command needs to contain users public key, either as an
argument or attachment or any other way the plugin might get it.
* List key fingerprint and per-address/user key fingerprints need
to be stored somehow, directly in the mailing list model would make the most sense, but that's very specific so the plugin should store this itself. Although that means data duplication.
* Plugins don't seem to have a way to add features to the core REST
API, so exposing key administration for Postorious that way is out.
+ Some questions that I had in my original proposal: + Is exposing key management through the REST api and Postorius a
good idea at all? Those have very different level of access control, changing a key on a list requires a signed request + signed confirmation token whereas doing it in Postorius might only require a password. + A way of sharing the lists public key that makes the user trust it the most.
# What I would like to definitely finish in the Community bonding period:
and have a meeting to discuss the proposal.
Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__/__\ #