[Mailman-Developers] [GSoC] Encrypted mailing lists

[Abhilash Raj]

Hi Jan,

Congratulations and welcome to Mailman!
Excerpts from Jan Jancar's message of May 10, 2017 5:07 pm:
> 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.

Awesome!

> 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
> jancar.jj at gmail.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:
> 
>  - As it was proposed on this list a plugin-like implementation of
> 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.

I feel like core already has the architecture(interfaces everywhere! :) that
will make it pretty easy to write plugins. If you feel you need some changes in
core to support your plugin better or plugins in general, I should be able to
help you with that part.

>  - I started evaluating how much of my current proposal can be 
> 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).
>  - So far it seems most functionality of encrypted mailing lists
> 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.

True, but there is a lot of trust already there on the password for
postorius. What if someone un-subscribes from the Postorius and then
re-subscribes sending along a key not owned by the user?

I don't know if that did make any sense, because as I understand the
subscription would be moderated and it would be up to List Admin to not allow
keys he doesn't recognize to be subscribed? Is there anything else except the
admin stopping some attacker from doing that?

>     + A way of sharing the lists public key that makes the user trust it
> the most.

I feel the key signed by the List Owner would be the best way to indentify the
lists public key. Maybe mandate signing by the Site Owner and List Owner/List
Owners?

> # What I would like to definitely finish in the Community bonding period:
> 
>  - Finish SMTPS/STARTTLS support for Mailman Core (really only needs 
> tests now): https://gitlab.com/J08nY/mailman/tree/mta-smtps-starttls
>  - Establish real-time communication channels with mentors (text/voice?)
> and have a meeting to discuss the proposal.

I am available as maxking on IRC(#mailman). I am a little busy for next week and
then we have Pycon, but I should be able to meet you anytime after Friday
26th. I am not very sure, but I will have some time on 17th too, I will let you
know?

>  - Add proper objective milestones to the proposal.
>  - Change the proposal to reflect movement towards a more plugin-like
> implementation.
> 
> 

I hope this summer is fun for you!

thanks,
Abhilash

--
thanks,
Abhilash Raj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170514/b5532994/attachment.sig>