[Mailman-Developers] Architecture for extra profile info

Stephen J. Turnbull stephen at xemacs.org
Fri Apr 19 03:06:58 CEST 2013


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".





More information about the Mailman-Developers mailing list