[1676] in Kerberos_V5_Development
Re: Beta 7 release plans
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri Aug 30 14:51:11 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krbdev@MIT.EDU
Date: Fri, 30 Aug 1996 14:50:58 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> If you could look over that list, especially items that have
>> your name next to them, and send me items which you know are done, or
>> other comments, I'd appreciate it. Thanks!!
I went through the several weeks of mail which happened while I was
gone, and added the new issues to the list. Here's what I added:
================
simple stuff:
- provide a simple way, by program or shell script, to create v4
srvtabs. [tytso]
- klist ccache not found error message has changed, breaking the
test. one or the other should be fixed. [hartmans]
- document that new ftp client won't work with old server [hartmans]
- krb4 doesn't treat 0 in the expiration time as "never expires"
[hartmans]
- loadv4 should convert an expiration date of 12/31/1999 to "never"
[hartmans]
harder stuff:
- make kprop/d use kdb5_util instead of kdb5_edit [bjaspan]
- a v4-imported db has all the last-pw-change times as zero, which is
1970, so all the passwords instantly expire. there should be some
provided mechanism (script, import flag, something) to set the
last-pw-change to something sane on v4 import if it was
zero. [hartmans]
- the subtleties of -pwexpire on a principal with a policy need to be
documented clearly. [bjaspan]
needs clarification:
- strange behavior wrt default policy and ref counts needs to be
investigated [hartmans, bjaspan]
- the code to deal with etypes which use the same cryptosystem,
including the md5 bit, is a mess.
barry suggests storing multiple records and not bothering to
optimize the database would work. marc suggests storing a
keytype field in the enctype record, for internal comparison
use.
the md5 support is, in fact, a complete mess wrt to backward
compatibility. we should figure out what the actual semantics
are, and document them clearly.
- gssapi apps are returning numeric com_err messages. [hartmans]
display_error_message calls krb5_init_ets(), so init and accept
shouldn't have to. if applications are calling com_err functions
on the minor status, they should be fixed.
- dbm_error and dbm_clearerr are causing portability problems
[epeisach, tytso]
we could remove these entries from the dispatch table, since
they are not used. this is simple. or, we could trash the
dispatch table entirely. this is more work, and probably
not appropriate for beta7
- do we want to build a shared libdb? [epeisach]
================
At this point, we should probably decide what needs to be addressed
for beta7, and what doesn't. The list of stuff to do with krb5 isn't
likely to be bounded any time soon.
Marc
