Richard Wackerbarth writes: > Perhaps I didn't understand you. I thought that you were > advocating the omission of any channels other than "shell" and > "localhost".
I'm saying that we should make appropriate Mailman components be OAuth clients (subject to site policy, per component), but try to avoid providing *any* authentication ourselves (localhost relies on existing shell access mechanisms via OS or SSH etc, HTTP Basic auth relies on Apache or other webserver, OAuth we'll have to build in, but the actual authentication is done by 3rd party providers). I suppose we'll have to provide moderation-by-password-in-headers and the traditional triple-handshake-by-mail for backward compatibility. Ah - I missed a very important channel: secure mail via OpenPGP. We need something like that (but again, the actual auth/auth process is done by GPG or PGP, we just rely on the token (signature) provided as a valid identification of a user). > I was trying to point out that HTTPS, oAuth, etc. should be equally > viable (and they don't REQUIRE that the components reside on the > shame host). I don't think anybody is opposed to exploring distributed architecture, and that implies securing inter-component communications. The question is how much of the security architecture we should provide ourselves. I advocate restricting that to the bare minimum, by which I mean "we don't *do* anything we don't *need* to do ourselves", not "we don't reimplement functionality that is available in Python packages or 3rd-party libraries we can wrap". _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://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: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9