Pasword quality pluggable interface project review

[Greg Hudson]

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.

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
  - 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).
  - char **errmsg_out: error message from plugin or NULL (memory
allocated by module).

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

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

* Bump the minor version of the password quality interface.

* Add a new check() method containing all of that gunk I listed above
(or better gunk, if I chose the wrong gunk).

* k5_pwqual_check() decides which method to invoke based on what the
module supports.

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