Deprecated Functions

[Sam Hartman]

>>>>> "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 &
    Brown,> krb5_get_in_tkt_with_password?

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
model?

krb5_get_init_creds_password should be used instead of
krb5_get_in_tkt_with_password