Hello Mailman developers,
I was planning to write a pgp-encryption plugin for Mailman 3 that manages one keypair per list and pubkeys of the subscribers. I'm considering to do it as my first-time Google Summer of Code project.
I have read the GSoC 2016 rules and the Mailman wiki GSoC 2016 pages. I will try to work myself more into the mailman-core sources the next few days and try to make an improvement (eg bugfix).
About me: I have been studying computer science in germany for two and a half years. I have sent patches to some libre, mainly C and C++, projects. I have only minor experience in Python but I'm used to learning by reading documentation and sources. Feel free to mail me if you have questions.
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. There is no stable pgp-aware mailserver at this time but there has been an unstable patch for mailman 2.1.51 and some other unstable encrypted list servers 2). This Project could also help to evaluate the Mailman 3 plugin system.
Some features could be:
- Automatic pubkey collection from inbound mail
- Outbound mail encryption and signature validation
- Automatic keypair generation for pgp-aware lists
- Inbound mail decryption and outbound mail signature
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
- A webinterface
- PGP Information in the messages (e.g. was the incoming mail signed by a trusted subscriber?)
- 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)
- pgp-aware command system. (eg optionally only accept admin mail commands from signature-verified mail admins)
Features 1.-5. are essential.
Thoughts on Implementation: pygpgme could be used for encryption which might easily enable S/MIME as well. Keys could be stored in the filesystem or in databases using SQLAlchemy. The encryption step could be implemented as a pipeline.
Encrypted lists in mailman would be great, I think I can implement the plugin myself but I will need help to ensure the reliability and security of the plugin.
What are your thoughts on pgp in Mailman 3?
Is this a suitable Project for the Google Summer of Code 2016? Would anyone be interested in becoming my mentor for this project?
Thank you, Jonas
Hi Jonas,
On 27 February 2016 at 10:35, Jonas <jonax@openmailbox.org> wrote:
Hello Mailman developers,
I was planning to write a pgp-encryption plugin for Mailman 3 that manages one keypair per list and pubkeys of the subscribers. I'm considering to do it as my first-time Google Summer of Code project.
Welcome!
I have read the GSoC 2016 rules and the Mailman wiki GSoC 2016 pages. I will try to work myself more into the mailman-core sources the next few days and try to make an improvement (eg bugfix).
About me: I have been studying computer science in germany for two and a half years. I have sent patches to some libre, mainly C and C++, projects. I have only minor experience in Python but I'm used to learning by reading documentation and sources. Feel free to mail me if you have questions.
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. There is no stable pgp-aware mailserver at this time but there has been an unstable patch for mailman 2.1.51 and some other unstable encrypted list servers 2). This Project could also help to evaluate the Mailman 3 plugin system.
If you don't know, I worked on this project some time back in GSoC 2013. The current state of that project is not very good and probably needs a *lot* of rebasing to do. I have been thinking about revisiting the project, but haven't been able to. I don't mind another GSoC for the same project if you can put up a proposal that would land the project in a better end state than I did ;-).
Here is a link1 to discussions that have already been done before on this idea. Please read it carefully as there has been a pretty extensive discussion on the security model and usability of such an implementation.
I have a few small questions doubts about your features below...
Some features could be:
- Automatic pubkey collection from inbound mail
What happens if I send a forged email with some user's email address as FROM and use a fake key? Automatic public key collection isn't a very good idea, you should be *very* careful about how you handle public keys.
- Outbound mail encryption and signature validation
I would suggest you keep encryption as a part of extended goals in case of GSoC. You'd be surprised how many students are not able to finish their proposal in time. I don't say they did not do good work, just that they did not make a good estimate of their time which is a good skill one should have.
- Automatic keypair generation for pgp-aware lists
Just to let you know, generating keys in virtual environments is not that easy due to less available randomness as compared to PCs.
- Inbound mail decryption and outbound mail signature
Can you elaborate on this? Shouldn't both be working differently? Encrypted emails distributed as encrypted email and signed email distributed as signed.
- A mailinterface for organizing the encrypted lists, subscribers public keys and trust levels
I would like to know more on how you plan to do this.
- A webinterface
Can be integrated in Postorius (Mailman 3's default web UI)
- PGP Information in the messages (e.g. was the incoming mail signed by a trusted subscriber?)
- 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)
- pgp-aware command system. (eg optionally only accept admin mail commands from signature-verified mail admins)
Features 1.-5. are essential.
Thoughts on Implementation: pygpgme could be used for encryption which might easily enable S/MIME as well. Keys could be stored in the filesystem or in databases using SQLAlchemy. The encryption step could be implemented as a pipeline.
Encrypted lists in mailman would be great, I think I can implement the plugin myself but I will need help to ensure the reliability and security of the plugin.
What are your thoughts on pgp in Mailman 3?
Is this a suitable Project for the Google Summer of Code 2016?
I think so.
Would anyone be interested in becoming my mentor for this project?
I can, depending on your application.
Thank you, Jonas
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40g...
Security Policy: http://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj
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
participants (3)
-
Abhilash Raj -
Jonas -
Stephen J. Turnbull