From owner-freebsd-bugs Mon Mar 16 07:40:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA03983 for freebsd-bugs-outgoing; Mon, 16 Mar 1998 07:40:13 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: (from gnats@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA03914; Mon, 16 Mar 1998 07:40:07 -0800 (PST) (envelope-from gnats) Date: Mon, 16 Mar 1998 07:40:07 -0800 (PST) Message-Id: <199803161540.HAA03914@hub.freebsd.org> To: freebsd-bugs Cc: From: Robert Watson Subject: Re: bin/6000: kerberosIV kadmin -- default entry year-2000 stupid Reply-To: Robert Watson Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/6000; it has been noted by GNATS. From: Robert Watson To: Garrett Wollman Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/6000: kerberosIV kadmin -- default entry year-2000 stupid Date: Mon, 16 Mar 1998 10:33:32 -0500 (EST) On Mon, 16 Mar 1998, Garrett Wollman wrote: > < > > Change the constant to something more reasonable, like say 2009-12-31, > > which is ten years later than the old default (hence my choice for > > accounts). Maybe > > Unfortunately, this will hose the Kerberos v5 upgrade procedure, which > knows about the long-standing (since the mid-80s) default expiration > time and automatically translates v4 principals expiring 1999-12-31 > into v5 principals with no expiration date. Perhaps we need a statement from the FreeBSD core people involved as to whether they anticipate upgrading FreeBSD to KerberosV in the next year months. Leaving it any longer would not, I think, allow people to benefit from the upgrade procedure you require. Large organizations relying on a FreeBSD kerberos IV server would probably desire/require longer than the remaining ~9 months until the expiration to do the transition. This is a year-2000 bug in that apparently no one thought that KerberosIV would last this long :). Since FreeBSD claims to be year-2000 compliant, this is certainly something one would want to fix. It's also not clear that I would want to convert accounts expiring on that date to accounts with no expiration, also. :) In the mean time, the default value is really not very useful. The non-kth distribution appeared to default the expiry time to some other value -- I think either the oldest key in the database, or the key that is used to add the new key. This behavior was useful, as it didn't require me to type an expiration again for every key. An un-useful default is not really such a great thing. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message