[Mailman-Developers] Encrypted lists are still a valid GSoC project, in case you were wondering.

[Terri Oda]

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