GSSAPI library compatibility between MIT releases

[Sam Hartman]

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:

    Cesar> Thanks Sam - two more question (below)
>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
    Cesar> I was wondering if someone from MIT can make a statement
    Cesar> regarding library/binary compatibility from one release to
    Cesar> the next of the GSSAPI libraries - I won't ask about
    Cesar> libkrb5 and related libs.

    Sam> To my knowledge, MIT has not broken ABI compatibility since
    Sam> before 1.2.0 for libkrb5, libk5crypto, or libgssapi_krb5 on
    Sam> Unix.  We have not broken ABI compatibility since KFM 4.5 or
    Sam> KFW 2.5.  I actually believe the constraints for KFW and KFM
    Sam> are much wider than that, but I know those are true.

    Cesar> Considering statement in last paragraph below, does this
    Cesar> then also apply to lib_comerr?

More or less.  We are certainly committed to stable com_err, although
it may have broken more recently than the other libraries.  It has not
broken since 1.2.5 and possibly has been stable much longer than that.

    Sam> We've decided that the public API (what you get from krb5.h,
    Sam> That said, our efforts to make the ABI stable may not be
    Sam> enough.  You need to look at the stability of all the
    Sam> libraries that you link against directly or indirectly when
    Sam> you pull in Kerberos.  If those don't have particularly
    Sam> stable ABIs, they may create problems for running old
    Sam> Kerberos applications.

    Cesar> One last question (which shows my ignorance on this
    Cesar> subject), if I'm always linking with a set of libraries
    Cesar> from the *same* MIT release (that is e.g., I don't mix
    Cesar> 1.3.1 libgssapi_krb5 and 1.2.8 libkrb5) and my app's only
    Cesar> lib dependency is libgssapi_krb5 (and I only reference
    Cesar> symbols from libgssapi_krb5), need I worry about say an ABI
    Cesar> change to libkrb5 in such a case? (I would suspect not, but
    Cesar> like I said, I'm somewhat ignorant on this matter).

An ABI change to libkrb5, probably not.  But no such application
exists.  You probably call C library functions like gethostbyname, may
call the same regex library we do, etc.  As we start adding
internationalization support to our libraries, twe will increase the
set of dependencies our libraries have.  If your applications has
intersecting dependencies, and one of those dependencies changes its
ABI, then either your application or our library may break if linked
into the same address space.

All depends or on a complex mess of platform dependencies like
versioned symbols, shared library linker options, etc.