On 2017-03-22 6:27 PM, Barry Warsaw wrote:
I should state for the record that my personal interest in this feature isn't so much encrypted mailing lists per se, but the architectural and design pressure it will put on Mailman 3, and our responses to that. Encrypted lists are the kinds of things I want to make possible with Mailman 3, so the APIs, hooks, configurations, and plugins that would be needed to implement encrypted lists (assuming, IMHO correctly that they won't be integrated into the core) will be of use to others who want to do Interesting Things with mailing lists.
I just want to pull this out and make sure students have seen it, because I know a lot of folk will see a discussion like the one we've had on the challenges and assume that "this is hard to do" means "this project is a waste of time and I should find another org to work with." And that's not true at all!
As Barry says, this is an interesting project for Mailman for many reasons that have nothing to do with encryption and everything to do with how to build a moderately complex system that hooks into Mailman. Those reasons are still valid regardless of how you feel about encryption. :)
More than that, GSoC's goal is generally *not* that students produce perfect workable code (you can sort of tell this by the fact that the code doesn't even have to be used by the organization providing mentors!) but rather to get students experience working in open source communities, learning new architectures, and working on real-world problems. Again, even if everyone everywhere is compromised, this is an interesting enough problem that meets all those other needs. When Stephen floated this idea, I thought it was great because on top of learning about mailman, it gives students a chance to work in a challenging security problem as well. Getting encryption even partially right is a thing that developers struggle with (my day job involves helping open source dev teams understand security) and a little experience tends to go a long way when it comes to future understanding of threat models and other key concepts in defining security.
It's also worth noting that one of the reasons this was chosen was also that this *isnt* an urgently-needed release-blocking feature for Mailman, but rather a "nice to have" that someone can work on without quite as much pressure. Again, this is great for a student project in ways that it might not be ideal for a core developer.
Basically, don't just read "Why Johnny Can't Encrypt" [1] and assume the problem of encrypted is dead and never will be solved. As my PhD supervisor used to say "you should look at impossible, insolvable problems as research opportunities rather than dead ends. That's science." :)
[1] https://www.usenix.org/conference/8th-usenix-security-symposium/why-johnny-cant-encrypt-usability-evaluation-pgp-50
_______________________________________________ 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
