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 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.
More information about the krbdev
mailing list