Draft kadmind plugin API (2007-04-27)

[Sam Hartman]

This looks reasonably good.

In response to your footnotes:

My preference is that you work with Ken to find a solution to [1].  I
care more about the usability of the API and the ease withwhich we can
add new plugin interfaces than I do about sharp abstractions between
k5support and libkrb5.  I care a lot about removing duplication of
code.  ,Reecoding loops to deal with plugins in libkadm5srv, libkrb5,
the kdc, etc, is undesirable and I believe this is already going on.
Minimizing the complexity of those loops by moving code into
anabstraction is good.  I don't think there are parts of our code that
could not somehow get a krb5_context if they needed one.  Having
libk5support link against libkrb5 is potentially problematic.

[2] Passwords in k5crypto are treated as krb5_data; the string2key
function certainly can deal with nulls.  So, at the kerberos level at
least passwords are not C strings.  If you do treat passwords as
length+data please use krb5_data.  Also, if you do this in your
implementation please do null terminate.

[3] no thoughts

[4] No real thoughts.