Pasword quality pluggable interface project review

[Nicolas Williams]

On Mon, Aug 30, 2010 at 07:12:54PM -0400, Greg Hudson wrote:
> On Mon, 2010-08-30 at 18:22 -0400, Sam Hartman wrote:
> > I can understand deferring revising our set-change password support.
> > However, as Russ pointed out, the existing change protocol has a way for
> > a text error to come back--Heimdal does that.  I think we need to at
> > least support this in the plugin interface even if you don't write the
> > glue now to make it work.
> 
> So, my concern about doing it now is that we'll do it wrong now and have
> no way of knowing it until later.

There's a user on the client side.  They can read text [provided it's
localized].  Text is all they need.  As evidence I offer my experience
with web-based password change pages:

All web-based password change interface I've ever used (sadly, I've used
many) use text to describe password quality policies.  Some also use
JavaScript to tell you if your password fails [some] policy immediately
when you tab to the "new password again" field.  Such JavaScript, if
any, is sent by the server.

We only need a policy code when the server can't send HTML + scripts to
the client, and even then it's not a big deal to use a "generic" code if
we can show the user some text [in a language they can read].

So, what could we be missing, besides lang tags and generic text?  Two
things:

1) A way to get a list of policy codes to be "enforced" by the client (if
   there's a smart client).  That is, the client start by getting a list
   of policy codes and a [localized text description of all policies in
   effect] from the server.

2) A way to get HTML + JavaScript to send to the client.

We almost certainly don't care about (2) here.  So, really, just (1).

> Here's the simplest proposal I can imagine for including this support in
> the plugin API:
> 
> * Add a new error code KADM5_PASS_Q_GENERIC.
> 
> * Add the following arguments to the check method:
>   - const char **languages: null-terminated list of client language tags
> or NULL

Or make it a comma-separated list of lang tags.  Then it can be a const
char *.

>   - char **language_out: language chosen by plugin, or NULL (memory
> allocated by module; we can't simply point into languages because fuzzy
> matches are a possibility).

The chosen lang tag is not that important.  It's not needed for
rendering, and the user will be able to figure it out by themselves.

>   - char **errmsg_out: error message from plugin or NULL (memory
> allocated by module).

Yes.  Or you could just provide one big buffer...  Since you'll
eventually run into a type of plugin where module-allocated outputs are
unavoidable you might as well address this now.

> * Add a new method to free *language_out and another new method to free
> *errmsg_out.  Or perhaps just one method to free a module-allocated
> string.

Yes.

> By contrast, if we ignore the problem now, here's what we have to do
> later when we're prepared to fully handle it:

But the errmsg_out can be used _now_.  No need for a new protocol for
that.  It'd be very odd to have a plugin that fails a password without
giving the user any guidance whatsoever as to what they did wrong.

> As a general rule, I believe it's better to be prepared to change later
> than it is to half-accomodate future requirements now.

errmsg_out is a requirement now.