>Number:         9095
>Category:       y2k
>Synopsis:       Y2K-related bugs in domestic kerberosIV code
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    y2k-manager (NetBSD Year 2000 bug manager)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan  1 01:36:00 2000
>Last-Modified:
>Originator:     William O Ferry
>Organization:
>Release:        <NetBSD-current source date> SUPed on 12/15/1999 at 7:45am PST
>Environment:
	
System: NetBSD slipstream.wofme.com 1.4L NetBSD 1.4L (kernel) #13: Fri Oct 15 23:47:09 PDT 1999     root@slipstream.wofme.com:/usr/obj.i386/kernel i386

>Description:
	
I have encountered at least two bugs in NetBSD's kerberosIV code since the
transition to 2000, I suspect there may be a few more lying in the code.

The first problem is not a Y2K bug precisely, simply a bug MIT chose to crop
up at 12/31/99 11:59pm EST.  kdb_init hardcodes this date as the expiration
for all of the entries it creates in the KDB.  This means that any databases
created from this point on would likely be expired right from the start (this
is why I marked this bug as critical).

Additionally, certain routines in libkrb and such for logging use the tm_year
value directly assuming a 2-digit value, which now that we are in 2000 the
value is 100, causing dates to come out with the year field being "100".
>How-To-Repeat:
	
Try to kinit to a NetBSD kerberos server after midnight EST on 1/1/2000,
watch it fail with a "principal expired" error.  Similarly check kerberos.log
to find that it is printing dates such as "01-Jan-100".

As a workaround for the principal expired errors, one should be able to do
the following to get their kerberos server back up and running:
kdb_util dump filename
vi filename
[change all strings of 200001010459 to some other value, I used 2010...]
kdb_util load filename
(may need to kill/restart kerberos daemon)
>Fix:
	
The code that should be fixed is at lines 77-78 in
domestic/usr.sbin/kdb_init/kdb_init.c, with the comment "Happy new century".

	Rather than hardcoding an expiration date, we probably should:
Make it expire a fixed amount of time after it is created (e.g. 10 years)
Have kdb_init prompt for an expiration date (the preferred way, IMO)

	Additionally, all uses of tm_year in the kerberosIV code should
probably be rewritten to properly handle years after 1999.  The places it is
used for the log messages are in domestic/lib/libkrb/klog.c (line 93) and
domestic/usr.sbin/kerberos/kerberos.c (line 186).  tm->tm_year should
probably add 1900, and the format string should print the 4 digit year, not 2.

	There are many other places where tm_year is used in the code, also
possibly incorrectly for Y2K.  Sometimes it appears to be used on input,
allowing a value less than 1900 to be enterred and automatically adding 1900
to it.  Not sure if these should also be fixed.
>Audit-Trail:
>Unformatted: