[Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

Steve,

Again, we agree. (Something must be wrong :) ) I think that it is important that "we" (the senior developers and mentors) assure that we maintain a structure whereby each of the student proposals can proceed at the same time.

Thus, for example, someone working on the User interface can do so without requiring the "secure" mail features.
At the same time, we provide a place (Eg. the Credentials store) that can be used to hold public keys associated with individual subscribers.

Now I will admit that I haven't thought about the criteria associated with permitting someone to add a public key-->user association. But, within whatever policy is needed, we have a method to handle the storage and the framework within which the system can "GetUserByCredential()", etc.

Richard

On Apr 30, 2013, at 12:28 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> Terri Oda writes:
> 
>> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will 
>> ONLY be supporting Mozilla Persona and passwords as authentication 
>> methods.
> 
>> 3.  While I agree that thinking about these things in advance is useful, 
>> I think this discussion is starting to crowd out discussions of
>> time-sensitive things like students' GSoC applications and
>> architectural choices that directly impact how they write said
>> applications.
> 
> Hold on!  Who's "we" and what is being released?  There are at least 3
> more or less separate projects here (Mailman core, Postorius, and
> HyperKitty).  For login of the webapps Postorius and HyperKitty, I
> certainly agree that aiming releasing them simultaneously with core
> 3.0, focusing on a particular authn mechanism (and given work done at
> the sprints, it should be Persona) is appropriate.
> 
> But Mailman 3.0 is *not* the only item on the agenda here.  We have a
> pile of GSoC students who want to implement various forms of authn for
> Mailman core functionality (secure lists) and some REST API (not clear
> to me which subproject these adhere to, the core Mailman REST API or a
> new one to be provided by Postorius).  AFAICT, *Persona is not
> appropriate* for these use cases, as it implies interactive use of a
> full-featured web browser.
> 
> Are you saying that (despite our ideas page) these proposals are a
> priori nearly unacceptable?  It's also rather late in the process to
> change the rules on the students: if experience is any guide, Melange
> availability is going to start deteriorating soon.
> 
>> So... can we please backburner parts of this discussion until after
>> GSoC so that we don't make it impossible for anyone to start on any
>> project involving extra profile info? I don't want to bog down a
>> student with the need to make this choice and work with these
>> decisions at this stage.
> 
> Actually, there aren't any students explicitly discussing extra profile
> information in their proposals.  They talk airily about "extended REST
> API" or similarly generic terms.  None talk about storage or
> representation of profile information.  (OK, it was 3am, my memory is
> fallible.  I don't remember any, though.)
> 
> 
>> For the purposes of GSoC this summer:
>> 
>> Authentication for the purposes of the extra profile info data store 
>> will be provided by either Persona through the web interface or 
>> passwords.
> 
> OK.
> 
>> Yes, even internally for the REST interface: passwords+localhost
>> are good enough for Mailman Core right now, so it's good enough for
>> anything else we do short-term.
> 
> That's going to strongly bias decision-making against at least one
> REST API proposal, which was made in good faith.
> 
> It also formally seems to rule out the secure lists proposal, which
> obviously depends on an off-line non-localhost authn protocol (based
> on OpenPGP or S/MIME).  Is that your intention?
> 
> Regards,