Change in behavior for krb5_get_credentials()

[Sam Hartman]

>>>>> "John" == John Hascall <john at iastate.edu> writes:

    >> I am writing to request feedback on a change I have committed
    >> to the cvs...

    >> The change I have committed as RT ticket 3029 is to ignore any
    >> error codes returned by a call to krb5_cc_store_creds() from
    >> within the krb5_get_credentials() call.  The purpose of the
    >> krb5_get_credentials() call is to obtain a valid set of
    >> credentials.  The purpose of the krb5_cc_store_creds() call is
    >> to optimize the behavior for future calls.  As I see it, if the
    >> credentials are valid that is all the caller of
    >> krb5_get_credentials() should be concerned with.  Any
    >> KRB5_CC_xxxx errors which were received would have to be
    >> ignored anyway by the caller.
    >> 
    >> If anyone sees a reason for treating this otherwise, please let
    >> us know.

    John> I have code which this could break.  If
    John> krb5_get_credentials() returns success, I assume (rightly so
    John> up until now) that future calls can specify the
    John> KRB5_GC_CACHED option.  May I suggest
    John> KRB5_GC_IGNORE_STORE_ERRORS?


So we're going to break code somehow.  Currently there is a lot of
code that is broken because of memory leaks.  We cannot keep the
current behavior.  If we change the behavior to free the credentials
and return an error, then we will break applications that depend on
those credentials being valid.  It might be acceptable to do that but
whatever we do we're going to have an API change because the current
API is undocumented to the point of being buggy.

I think reasonable options are:

1)  Jeff's change.

2) Free the credentials on store error and return failure.  Add a flag
   saying that we are prepared to accept credentials on error and use that in GSSAPI.

3) Jeff's change plus an flag saying you want store errors.  Clearly
   document whether you get credentials on store errors. (I vote no)

--Sam