Jonas writes:
The Project Idea: Encrypted malinglists have been been a much-requested feature in mailman 2 and I would like to run some encrypted mailinglists myself.
I see Abhilash has already mentioned that he has done some work on crypto (PGP) in Mailman 3. I'll let him explain that.
I agree that this capability is very desirable for some use cases, so I too welcome your application.
There is no stable pgp-aware mailserver
Please be careful about terminology. In software, the suffix "-aware" is pretty weak. It could mean as little as "oh, this MIME body has a signature, so we should not touch the MIME body" (eg, to add the usual footer). I'm not sure what would be appropriate terminology here (the problem is that requirements are completely undefined, but in security applications requirements must be precisely specified -- if somebody uses your application inappropriately because you built something other than what they need, "I'm sorry" doesn't begin to cover the damage). "PGP-enabled" will do for now.
Some features could be:
- Automatic pubkey collection from inbound mail
Collect, maybe, but enable, no. Mail as such cannot be trusted. You would basically need to do a triple handshake with the address to confirm that that address indeed has access to that key and the key's owner has the right to use that address.
- Outbound mail encryption and signature validation
- Inbound mail decryption and outbound mail signature
I don't understand these pairs. Why encrypt mail *to* the server if it's only going to be decrypted on the way out? Why encrypt outgoing posts if they might have been read in the clear before being received? End-to-end encryption or signature or both seems to be the right thing.
- Automatic keypair generation for pgp-aware lists
Out of scope for one summer IMHO. It's not obvious what the security implications are. Better to do key generation off-line.
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
- A webinterface
These too are out of scope. Again, security implications are unclear.
- PGP Information in the messages (e.g. was the incoming mail signed by a trusted subscriber?)
What does "trusted" mean?
- Optionally forced encryption (such a list never sends mail to an adress to which it can't encrypt with a pubkey that has a certain level of trust and/or won't accept inbound mail in plaintext)
- Optionally forced signature (inbound mail to the list has to be signed with a key that has a certain level of trust in order to be published)
I don't understand how you propose to manage "trust levels". And "optional", if you want it optional, why are you bothering in the first place? That just makes the whole list unreliable as far as security goes, because you never know what's going to happen.
- pgp-aware command system. (eg optionally only accept admin mail commands from signature-verified mail admins)
I don't understand this. Mailman doesn't actually have that many admin mail commands, and the signature requirement is easily bypassed by doing the same operations from the web.
What are your thoughts on pgp in Mailman 3?
My thought is "what is your threat model"?
Is this a suitable Project for the Google Summer of Code 2016?
Yes, crypto support (both encryption and signatures) are a FAQ. However, nobody has ever really provided specific requirements (ie, the threat model to defend against), so it's very hard to decide what to do, and documentation of whatever is done would be impossible.
Would anyone be interested in becoming my mentor for this project?
Subject to acceptance, I can be a co-mentor (I was Abhilash's mentor) but probably cannot be primary (I have another proposed project where I'm the obvious primary since I'm the only one who currently has the relevant knowledge).
As far as acceptance goes, please see http://wiki.list.org/DEV/Google_Summer_of_Code_2016 for information about our requirements and procedures for student applications.
Regards, Steve