Yassin ElBedwihy via Mailman-Developers writes: > I'm curious: What's the plan for implementing forward secrecy?
I have none. The mailing list needs to know the private key in order to reencrypt the session key for the subscribers. It needs to distribute the public key to senders somehow. If that is done on a per-post basis, the distribution mechanism has to be implemented *in Mailman* with some kind of authentication for senders. Then that needs to be integrated with the senders' mail clients, somehow. There would need to be at minimum a proof of concept for some MUA. Key distribution is a bigger project than the mailing list changes, I suspect. And what are you going to do about all those clear copies sitting in recipient systems? If I were an attacker, I would assume that the host of a "secret list" would be well-defended, but that's unlikely to be true of all recipients. > I'd also love if the mentors of the project would guide me on what > to do next. The first thing to do is to read the Google Contributor's Guide, then ours. That lays out the basic process for applying, which includes successfully contributing a merge request. (That request can be trivial (fix a typo in a comment), the point is to be familiar with our contribution process.) Then get signed up for the mailing lists ([email protected] and [email protected]) and the #mailman channel on IRC where historically realtime conversations have taken place. One that's done, you can think about what your goals for the project are. Encrypted lists are requested or suggested a lot, that's why we have it listed as a task. However, none of the crypto people I follow think they can be useful as a serious security tool, because the email system is very complex and open at almost every point, while mailing lists introduce further attack surface. I would suggest starting with the most basic project, assuming away the man-in-the-middle nature of Mailman itself and the problems of forward secrecy, and just get the key distribution and reencryption features implemented. You probably also want to deactivate all features that allow users to subscribe themselves for encrypted lists as well as the ability to change the status of a list from encrypted to not so. Documentation of usage and limitations is going to be very important. Do this throughout and make notes to yourself of usage issues to remediate (have you used GPG recently?) and limitations you'd like to remove if you have time. > What I should read up on, etc. This project looks fun! There seems to be a lot of work going on in the cryptography/privacy community. I found this blog rather interesting, although it's only peripherally connected to encrypted email (which it deprecates hard). https://www.soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ I don't know whether it would be worth looking into some of the alternative encryption applications mentioned there instead of PGP-based encryption. Interestingly, these folks also deprecate the OpenSSL suite somewhat. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
