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
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.
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:
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
Show quoted text
>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>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:
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.
Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:
>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:
Show quoted text
>Unformatted: