foolproof method of determining Kerberos version?

Sam Hartman hartmans at MIT.EDU
Wed Jan 21 07:48:30 EST 2004

>>>>> "Kevin" == Kevin Coffman <kwc at> writes:

    Kevin> CITI's NFSv4 code for Linux needs to pass GSS-API context
    Kevin> information to/from the kernel.  This requires knowledge of
    Kevin> the private Kerberos structure krb5_gss_ctx_id_rec which is
    Kevin> defined in lib/gssapi/krb5/gssapiP_krb5.h.  This structure
    Kevin> changes in 1.3.2.  Is there a foolproof way to determine at
    Kevin> compile-time and/or run-time what version of Kerberos we
    Kevin> are using so we can deal with this?  Is there a better way
    Kevin> for us to deal with this?
Yes.  ANy of the two options would have been more acceptable:

1) Actually talk to us before shipping code that depends on our
    internal data structures, creates a support commitment for us and
    makes us look bad when you ship something that violates our
    abstractions.  Seriously, people have complained to us about the
    fact that we changed our internal structures and it broke your
    code.  That's not acceptable to us, and it makes us much less
    interested in helping you in the future.

We can probably patch this, but I think that MIT should get a clear
understanding of how the existing broken code is end of lifed before
moving forward to introduce a solution.

2) Kerberos is open source.  You could have forked the code,
    introduced your own private APIs and made it clear that your code
    only worked with Umich Kerberos--a dirivitive or MIT Kerberos and
    would not work with the stock MIT distribution.  Yes, this would
    have made us upset, but not nearly as upset as shipping code that
    depends on private structures.

we certainly don't consider having your code check the version of MIT
Kerberos to be a valid strategy for dealing with this.

More information about the krbdev mailing list