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