[1789] in Kerberos_V5_Development
V1.0 todo list
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Sep 26 00:29:43 1996
Date: Thu, 26 Sep 1996 00:29:38 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbcore@MIT.EDU
I have created a preliminary todo list for the V1.0 release and placed
it in an RCS controlled file in /mit/krbdev/v1_0_todo.
My goal is trying to present somethingl that will get
discussion started and try to get people to consider the issues, not
to make any particular decisions. So, if you disagree with the todo
list, you should change it. Hopefully everyone will look at the list
and make appropriate changes. Then (fairly soon), Ted can resolve
disagreements and approve a todo list.
I started with the left-over post-beta7 merge issues and added
things that have been discussed. I almost certainly forgot some other
issues. I have included the preliminary list below.
issue list for krb5 V1.0
Required for Release
- getdate.y loses when durations are specified as integers [hartmans,
bjaspan, eichin]
does this need a fix, or is it only a doc bug?
I think that ebcause of the bug reports we have been having, this should be dealt with. [hartmans]
- docs need review
- kadmin usage messages are fixed; they should be automagic based
on the attribute lists [hartmans]
- document that new ftp client won't work with old server [hartmans]
- loadv4 should convert an expiration date of 12/31/1999 to "never"
[hartmans] ?
Reasonable Goals for Release
- purify kadmind [tytso]
- document v5passwdd [epeisach]
- 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]
- provide a simple way, by program or shell script, to create v4
srvtabs. [tytso]
Undecided
- add a mechanism for extracting a key w/o changing it [hartmans]
Is this a priority for beta7? As barry points out, it is
possible on the server side, but code would need to be
written.
If kdb5_edit is included in Beta7, this is possible. I
certainly don't think this is a priority. [hartmans]
This probably shouldn't go in because I don't see anyone else
caring enough to implement and I don't have time. It would be useful
long-term, though.
- do we want to build a shared libdb? [epeisach]
Hold off on These
- 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. I think marc won this one. [hartmans]
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.
- build system redesign [tlyu]
- Handle application configuration such as enable encryption for everything.
