Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)
X-RT-Original-Encoding: iso-8859-1
Content-Length: 3319

From kst@SDSC.EDU  Tue Sep 14 02:27:49 1999
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id CAA20501 for <bugs@RT-11.MIT.EDU>; Tue, 14 Sep 1999 02:27:48 -0400
Received: from postal.sdsc.edu by MIT.EDU with SMTP
	id AA07052; Tue, 14 Sep 99 02:27:46 EDT
Received: from elmak (IDENT:K8SdmGp/3HrmC3SABLSjW/CGZiLwRyif@elmak.sdsc.edu [132.249.22.138])
	by postal.sdsc.edu (8.9.3/8.9.3/SDSCserver-16) with SMTP id XAA15590;
	Mon, 13 Sep 1999 23:27:45 -0700 (PDT)
Received: by elmak (SMI-8.6/1.11-client)
	id XAA04020; Mon, 13 Sep 1999 23:27:45 -0700
Message-Id: <199909140627.XAA04020@elmak>
Date: Mon, 13 Sep 1999 23:27:45 -0700 (PDT)
From: Keith Thompson <kst@SDSC.EDU>
To: krb5-bugs@MIT.EDU
Cc: kst@SDSC.EDU (Keith Thompson)
Subject: Time glitches in krb5-1.0.6

>Number:         750
>Category:       krb5-libs
>Synopsis:       Time glitches in krb5-1.0.6
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    krb5-unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Tue Sep 14 02:28:00 EDT 1999
>Last-Modified:  Tue Feb 22 16:45:40 EST 2000
>Originator:     Keith Thompson <kst@SDSC.EDU>
>Organization:
>Release:        
>Environment:
>Description:
I would have used krb5-send-pr, as suggested in the README, but it
doesn't appear to have been built by "make".

In src/lib/krb5/os/gmt_mktime.c:

  assert_time(t->tm_year>=70);
  assert_time(t->tm_year<=138);

Hmm.  I'm not sure that last check is really necessary.  It's obviously
intended to fail after 2038, which is when a 32-bit signed time_t based
on 1970 overflows.  If properly written, though, the code should be
able to handle a 64-bit time_t; there should be no need for this check.
(There's probably a Y2100 bug in the leap year accumulation code.)

It might be considered as a check that the C library behaves sanely,
but I've never seen or heard of one that doesn't handle tm_year
correctly.

Remember, 2038 is only as far in the future now as Y2K was in 1961.

========================================================================

Also in src/lib/krb5/os/gmt_mktime.c:
  assert_time(t->tm_sec>=0);
  assert_time(t->tm_sec<=62);

In fact, the C standard guarantees tm_sec <= 61, and C9X guarantees
tm_sec <= 60.  (The C89 allowance for tm_sec == 61 resulted from a
misunderstanding -- in fact, there can't be 2 leap seconds in a single
minute.)  The above code incorrectly allows up to *3* leap seconds.

========================================================================

In src/lib/krb5/asn.1/asn1_encode.c :

  if (gtime == NULL ||
      gtime->tm_year > 9999 || gtime->tm_mon > 11 ||
      gtime->tm_mday > 31 || gtime->tm_hour > 23 ||
      gtime->tm_min > 59 || gtime->tm_sec > 59)
    return ASN1_BAD_GMTIME;

This doesn't allow for *any* leap seconds.  (I'll ignore the Y11900
error.  8-)})

-- 
Keith Thompson, San Diego Supercomputer Center  kst@sdsc.edu
<http://www.sdsc.edu/~kst/>  Office: 858-822-0853  Fax: 858-534-5077
"Oh my gosh!  You are SO ahead of your time!" -- anon.
>How-To-Repeat:
>Fix:
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: raeburn
Responsible-Changed-When: Tue Feb 22 16:45:34 2000
Responsible-Changed-Why:

>Unformatted: