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:
+ 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:
and what parts of this should be configurable and in what way / granularity?
I propose the following:
subscribe / unsubscribe), to stop replay of commands.
per list. [require/allow encrypted, require/allow signed]
+ A way of sharing the lists public key that makes the user trust it
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
I hope this summer is fun for you!
I think it will!
Jan ______________________________________________________ /\ # PGP: 362056ADA8F2F4E421565EF87F4A448FE68F329D /__\ # https://neuromancer.sk /\ /\ # Eastern Seaboard Phishing Authority /__/__\ #