[834] in Kerberos_V5_Development
Re: rearranging krb5 include files: please retain some sanity
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Jan 23 14:49:44 1995
Date: Mon, 23 Jan 1995 14:49:23 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: John Kohl <jtk@atria.com>
Cc: krbdev@MIT.EDU, proven@MIT.EDU, eichin@cygnus.com
In-Reply-To: John Kohl's message of Mon, 23 Jan 1995 12:18:20 -0500,
<9501231718.AA00886@banana>
Date: Mon, 23 Jan 1995 12:18:20 -0500
From: John Kohl <jtk@atria.com>
X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760
>>>>> "Ted" == o <Theodore> writes:
Ted> The basic idea which we're looking at is that what you export out to an
Ted> application writer will be a *single* krb5.h file. Hence, it can live
Ted> up in the top-level. ....
Ted> I expect that if a vendor ships Kerberos V5 bundled, it will install
Ted> krb5.h in /usr/include, or perhaps in /usr/local/include.
Ted> Does this still give you heartburn? If so, why?
Well, that's much less objectionable than my previous impression of what
was in the works. The only question that remains is whether at this
juncture it makes sense to be changing the include file name. Is there
some compelling reason to change the API by changing the name from
<krb5/krb5.h> to <krb5.h> ?
The API is changing in other ways, anyway, for Beta 5. The largest
change is that each krb5 function now takes a context argument, which
you can think of as a "library session context". The idea is that
eventually, all statically stored information will be stored in this
context structure, and there doesn't have to be any statically stored
state in the library at all.
I'm considering this to be our last chance to make any API changes
before the 1.0 release, so I'm going in to fix any breakages that I've
inherited from the original design. If I were doing it over again, I
would have done a lot of things differently, but I don't have the luxury
to do that. However, for those things which I can fix, I am planning on
doing so, even if that means changing the API.
Examples of API breakages: the keytab access functions don't include a
selector for which key type to you want to access --- we're only going
to be using DES forever, right? (Cough.)
Another example: The way the key_proc function works in get_in_tkt means
that preauthentication with a non-standard salting algorithm doesn't
work.
Yet another example (which I may or may not actually get around to
fixing before 1.0): The abstraction layer for the crypto layer is
something unspeakable; hard to understand and hard to use.
- Ted
