[Mailman-Developers] [GSoC] Encrypted mailing lists

[Jan Jancar]

Hey Abhilash!

On 05/14/2017 08:18 AM, Abhilash Raj wrote:
>>  - 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.

Yes, so far it has everything necessary. Some things I noted:

 - A plugin cannot create a Pipeline the same way it creates Handlers or Rules,
   it can only do so in a post_hook. Since the Pipeline classes are enumerated
   when initializing them.
   https://gitlab.com/mailman/mailman/blob/master/src/mailman/core/pipelines.py#L150
 - And then the issues I outlined in my previous email, which mainly stem from 
   the encrypted lists plugin having some pretty strong requirements on current 
   Mailman features.


>>     + 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?

Sure, subscription will be moderated and the List Admin will have to trust both
the address he is accepting and the key provided. However, this is something
we would like to stop, someone unsubscribing a user from an encrypted mailing
list with just a password and not access to his private key.

This is something that definitely needs comments. What actions should a
subscriber / unsubscribed user be able to do on an encrypted mailing list
with:
 - just a password
 - his private key
and what parts of this should be configurable and in what way / granularity?

I propose the following:
 - all email commands should require a signed confirmation (the same workflow as
subscribe / unsubscribe), to stop replay of commands.
 - posts should require being encrypted and signed, and this should be configurable
per list. [require/allow encrypted, require/allow signed]
 - Postorius user operations should also somehow require signed confirmation.


> 
>>     + 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?

Right, I also think that utilizing PGP web-of-trust the most, is the best
we can do here. Also just recently found out, schleuder (an encrypted mailing list
server) supports uploading signed list keys to it a will serve them with the signatures
from then on.


>> # 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?

Sure, I'm in #mailman and I have some questions better suited for irc, so you'll
definitely hear me there.

> 
>>  - 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!

I think it will!


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/20170516/4298d027/attachment.sig>