[7] in GSSAPI Development
Re: Testing and stuff
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Apr 26 13:46:53 1991
Date: Fri, 26 Apr 91 13:45:03 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Wray, Secure Systems Development, DTN 226-6106 26-Apr-1991
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 26-Apr-1991 0905's message of Fri, 26 Apr 91 07:16:10 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
I'm sending this reply to WRAY@ultra.enet.dec.com as well as to the
gssapi-dev@athena.mit.edu mailing list. So you (John Wray) should get
two copies of this, assuming the gods of DEC mail smile upon us. Can
you let me know whether or not WRAY@ultra.enet.dec.com works? Thanks!
(Gotta love the BITNET address verification tactics. :-)
I don't have a very strong preference in this area. The convention is for
#defines to be in upper-case, although the GSSAPI is using #defines where
constant declarations would be better (for compilers that support them), and
the conventions for constants are less firm. As I said, I don't have
a strong preference, so unless there are objections, we might as well
upper-case the error status names. Does anyone else feel strongly on
this issue?
I don't feel strongly about it, but I do think upper-casing the error
status names would make things a bit less confusing. What's really
important is that we both do the same thing.
Hmm. That's annoying. How about making the #defines give the real
values of the errors, not shifted right, rather than the values
within the field, and adjust the field extraction macros to do
likewise.... That would eliminate this problem with less of a
change. Comments?
That's also fine. Shall we agree to that?
>In attempting to code gss_accept_sec_context, I ran into a problem.
>When Kerberos does a krb5_rd_req(), it requires the sender's network
>address, and there's no place to pass that into gss_accept_sec_context.
There's some history involved in this issue - John Linn had better take this
one.
Can we address this soon? Kerberos will not be able to work with the
GSS API unless this problem is resolved, and we were hoping to get a
Beta release of Kerberos V5 out soon that would support the GSS API. If
we do not address this soon, I see three options 1) I code to my
original proposal and have a slightly non-confirming, but functional GSS
API, 2) we drop the GSS API from the beta Kerberos release, or 3) we
push back the beta release of Kerberos. Unfortunately, none of the
three options are particularily desireable.
- Ted
