hartmans at MIT.EDU
Thu Nov 17 15:14:45 EST 2005
>>>>> "Brown," == Brown, Deborah <deborah.brown at lmco.com> writes:
Brown,> clients internal to the Control Center. In stepping up
Brown,> from KRB5 1.2.7 to KRB5 1.3.4, two functions that we use
Brown,> have been deprecated -- krb5_get_in_tkt_with_skey &
Brown,> krb5_get_in_tkt_with_password. I know that we can
Brown,> continue to use them by setting KRB5_DEPRECATED to 1
Brown,> (which we have done and we do get clean compiles; we also
Brown,> had to set KRB5_PRIVATE). And, I have read in an internet
Brown,> newsgroup (Sam Hartman 9/8/2004) that as of version 1.4,
Brown,> the APIs still are not being removed. But, we still
Brown,> aren't completely comfortable with continuing to use them.
I'd be much more concerned about why you need to set krb5_private. If
you're needing to do that then either your code or our release is not
doing something optimal.
Brown,> My first question is, in general when APIs are made to be
Brown,> deprecated how do we determine what the equivalent
Brown,> replacements are?
We don't have a good answer for this. Perhaps we could add comments
in the header file recommending alternatives.
Brown,> And secondly, in this specific instance are there
Brown,> equivalent APIs available for krb5_get_in_tkt_with_skey &
There's not really a replacement for krb5_get_in_tkt_with_skey.
If you would be willing to describe what you're doing with this API
we'd be very interested. Is a keytab inappropriate for your usage
krb5_get_init_creds_password should be used instead of
More information about the krbdev