foolproof method of determining Kerberos version?

[Kevin Coffman]

Sam,
I think you are talking about a separate issue.  (Namely, the local
*umich-only* KDC change dealing with des-cbc-md5 that has caused problems
with kadmin.)  I am *very* sorry about any support burden that has caused
MIT.

What I am asking about here is a separate issue which I *am* talking to you
about *before* we ship code for NFSv4.  I just became aware of the use of
the private structure in our code and am looking for a mutually agreeable
solution.  Perhaps we could discuss this via telephone or off-list?

Kevin

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of
Sam Hartman
Sent: Wednesday, January 21, 2004 7:49 AM
To: kwc at citi.umich.edu
Cc: krbdev at mit.edu
Subject: Re: foolproof method of determining Kerberos version?

>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> 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.


_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev