How is an application supposed to know if a Kerberos library isthread safe?

[Jeffrey Altman]

Nicolas Williams wrote:

> Actually, I think the GSS interface should be:
> 
> OM_uint32 gss_inquire_mech_thread_safety(OM_uint32 *minor, gss_OID mech,
> 					 OM_uint32 *is_thread_safe);
> 
> This gets the "krb5" out of the function name and helps those of us who
> have mechs other than Kerberos V.
> 
> I'd like us to figure out how to use the gss namespaces for extensions
> (I'm working on the IANA I-D), but there should be no need to wait for
> that -- we can grandfather anything that ultimately doesn't fit any
> allocation rules.
> 
> Nico

While I agree that a generic interface is desirable.  I would not feel
comfortable extending the generic GSS API in the Kerberos 5 release 1.4 
which is currently in beta without the Kitten working group having had 
an opportunity to standardize it.

In private, you indicated that Sun would not include either 
krb5_is_thread_safe (because Solaris does not export krb5 apis) nor 
gss_krb5_is_thread_safe (because you want a generic interface.)  This
places us in a bit of an awkward situation.  We do not want to fracture
the Kerberos API namespace anymore then it already is and yet we need
to do something as part of the 1.4 release.

Is there some way that we can mark the API such that developers using
it know that it is not supported on all implementations without using
either KRB5_PRIVATE or KRB5_DEPRECATED?

Clearly once we add an new function to the public API we will not be
able to remove it.

Jeffrey Altman