foolproof method of determining Kerberos version?
kwc at citi.umich.edu
Wed Jan 21 17:54:34 EST 2004
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
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?
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of
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
More information about the krbdev