Proposal: krb5_get_init_creds_opt_set_change_password_prompt

Sam Hartman hartmans at MIT.EDU
Tue Dec 5 10:43:23 EST 2006


>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:

    Kevin> On 12/4/06, Sam Hartman <hartmans at mit.edu> wrote:
    >> >>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
    >> 
    Douglas> Kevin Coffman wrote:
    >>  >> Branch users/coffman/gic_opt_ext has my propoal for
    >> extending >> the get_init_creds_opt structure and making use of
    >> it to pass >> preauth options through the to preauth plugins.
    >> >>
    >> >> There is currently extra test code in kinit.c which does not
    >> >> belong.  Hopefully it is obvious.  There is currently *not*
    >> a >> compatibility function/macro to match Heimdal's >>
    >> krb5_get_init_creds_opt_set_pkinit() function.
    >> 
    Douglas> Since PAM_KRB5 is a common source routine that needs to
    Douglas> call krb5_get_init_creds_* it would be nice if both MIT
    Douglas> and Heimdal used the same API....
    >>  As I've said before, we cannot have a pkinit-specific entry
    >> point in libkrb5 for licensing reasons.

    Kevin> Now I'm a bit confused.  Is it "pkinit-specific" you're
    Kevin> opposed to, or the licensing issue of OpenSSL?  I don't
    Kevin> understand how having an entry point like this in libkrb5
    Kevin> ties it to the OpenSSL issue.

At least until there is a non-openssl implementation of pkinit I want
to be very careful about any public pkinit-related entry points.

Also, I believe that the pa-type-specific approach we've come up with
is architecturally better.

--Sam




More information about the krbdev mailing list