2038 date limit

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

2038 date limit

Chris Kottaridis
When trying to make a certificate for 30 years seems you run into the
2038 date limitation. Seems the code converts date to a signed int in
seconds since 1970 and now that we are within 30 years of the 2038 limit
we get hit by it. Using a date of (30 * 365) from now:

notBefore=Mar25 19:33:38 2008 GMT
notAfter=Feb 10 13:05:22 1902 GMT

Clearly it wrapped around and subtracted 68 years from 1970 instead of
adding 68 years.

Is there a plan to remove this limitation ?

I am seeing this on openssl-0.9.7m.

Thanks
    Chris Kottaridis    ([hidden email])

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Alan Buxey
Hi,
> When trying to make a certificate for 30 years seems you run into the
> 2038 date limitation. Seems the code converts date to a signed int in
> seconds since 1970 and now that we are within 30 years of the 2038 limit
> we get hit by it. Using a date of (30 * 365) from now:

thats the same date that i start to get problems with my Amiga

seriously 30 year certificate?


alan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Sendroiu Eugen
In reply to this post by Chris Kottaridis

One of the certificates from VeriSign that comes with Firefox is issued in 1996 and it lasts until 2028. That's 30+ years.

----- Original Message ----
From: "[hidden email]" <[hidden email]>
To: [hidden email]
Sent: Thursday, June 5, 2008 8:22:09 PM
Subject: Re: 2038 date limit

Hi,
> When trying to make a certificate for 30 years seems you run into the
> 2038 date limitation. Seems the code converts date to a signed int in
> seconds since 1970 and now that we are within 30 years of the 2038 limit
> we get hit by it. Using a date of (30 * 365) from now:

thats the same date that i start to get problems with my Amiga

seriously 30 year certificate?


alan
______________________________________________________________________
OpenSSL Project                                http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Chris Kottaridis
In reply to this post by Alan Buxey
>seriously 30 year certificate?

That was my initial response, but that's what a customer wants.

I was hoping to be retired before I had to worry about this limit. It
does seem to be something that people want to do and I was just
wondering if there was a plan in place to fix it. In checking the web on
this I found at least one site describing how to generate certificates
that made mention to not set the certificate value to over 2038 so it's
clear it's known and bumped into from time to time.

Is there a plan to circumvent the limit, as opposed to just saying stay
within 2038 ?

Thanks
    Chris Kottaridis    ([hidden email])

On Thu, 2008-06-05 at 18:22 +0100, [hidden email] wrote:

> Hi,
> > When trying to make a certificate for 30 years seems you run into the
> > 2038 date limitation. Seems the code converts date to a signed int in
> > seconds since 1970 and now that we are within 30 years of the 2038 limit
> > we get hit by it. Using a date of (30 * 365) from now:
>
> thats the same date that i start to get problems with my Amiga
>
> seriously 30 year certificate?
>
>
> alan
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Eljas Alakulppi
> Is there a plan to circumvent the limit, as opposed to just saying stay
> within 2038 ?
Afaik, the only current solution is to switch to 64bit openssl.

-Eljas Alakulppi
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Leonard F. Elia
In reply to this post by Chris Kottaridis
This problem is much bigger than OpenSSL. In fact, it is probably bigger
than Y2K because it will involve changes to most flavors of the Unix
operating system.  It is neither trivially solved, nor an unknown problem.

Chris Kottaridis wrote:
> Is there a plan to circumvent the limit, as opposed to just saying stay
> within 2038 ?
>  
--
Leonard F. Elia III, CISSP     757.864.5009
Sr. System Administrator
ConITS - NASA Langley Research Center
NCI Information Systems, Inc., Hampton VA


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Victor Duchovni
In reply to this post by Chris Kottaridis
On Thu, Jun 05, 2008 at 01:23:05PM -0600, Chris Kottaridis wrote:

> >seriously 30 year certificate?
>
> That was my initial response, but that's what a customer wants.
>
> I was hoping to be retired before I had to worry about this limit. It
> does seem to be something that people want to do and I was just
> wondering if there was a plan in place to fix it. In checking the web on
> this I found at least one site describing how to generate certificates
> that made mention to not set the certificate value to over 2038 so it's
> clear it's known and bumped into from time to time.
>
> Is there a plan to circumvent the limit, as opposed to just saying stay
> within 2038 ?

Suppose your machine is able to verify it (by deploying an SSL library
that has a 64-bit time_t), does it really help you? How well do you
control the population of clients that verify this certificate?

OpenSSL built in an LP64 compilation environment should (AFAIK) not have
any trouble with 2038.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Dr. Stephen Henson
In reply to this post by Chris Kottaridis
On Thu, Jun 05, 2008, Chris Kottaridis wrote:

> When trying to make a certificate for 30 years seems you run into the
> 2038 date limitation. Seems the code converts date to a signed int in
> seconds since 1970 and now that we are within 30 years of the 2038 limit
> we get hit by it. Using a date of (30 * 365) from now:
>
> notBefore=Mar25 19:33:38 2008 GMT
> notAfter=Feb 10 13:05:22 1902 GMT
>
> Clearly it wrapped around and subtracted 68 years from 1970 instead of
> adding 68 years.
>
> Is there a plan to remove this limitation ?
>
> I am seeing this on openssl-0.9.7m.
>

As has been mentioned this is caused by the time representation of the
underlying OS. OpenSSL relies on the OS routines to convert the time_t value
to appropriate date fields. If the time_t value wraps around you get the above
behaviour.

Changing this is would involve including independent date routines which don't
have this restriction. I did start on this some time ago but other higher
priority tasks (e.g. paid ones!) took over.

Note however that this doesn't affect OpenSSLs ability to *verify* date fields
in the far future. The technique used avoids time_t issues and it should
happily handle any date.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Alan Buxey
In reply to this post by Leonard F. Elia
Hi,
> This problem is much bigger than OpenSSL. In fact, it is probably bigger
> than Y2K because it will involve changes to most flavors of the Unix
> operating system.  It is neither trivially solved, nor an unknown problem.

move to 64bit - thats the only way to go beyond 2038 from the
unix epoch. however, until all clients (thats ALL clients - PDAs
etc etc) are 64bit too, you'll still have failures at the
client end of the SSL

alan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Chris Kottaridis
In reply to this post by Leonard F. Elia

On Thu, 2008-06-05 at 15:33 -0400, Leonard F. Elia wrote:
> In fact, it is probably bigger
> than Y2K because it will involve changes to most flavors of the Unix
> operating system.  It is neither trivially solved, nor an unknown
> problem.
>
I understand the issue, and like I said I was hoping to be retired
before it was an issue.

If we are just going to live with the limitation shouldn't there at
least be a check for the overflow and if so then send a message about
illegal date and not generate the certificate rather then generating a
certificate with a notAfter date prior to the notBefore date ?

Thanks
    Chris Kottaridis    ([hidden email])

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

Jim Adams
In reply to this post by Dr. Stephen Henson

What OS did you have this problem on?  I use Openssl 0.9.7m on Windows to generate
certificates, and I was able to generate certs beyond 2038 with no problem.  I did not
experience a problem until I tried to generate one that lasted beyond 2106, when the
entire 32-bit number overflows.  So Windows does not appear to have a signed/unsigned
int problem such as you report.

Jim Adams


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Dr. Stephen Henson
Sent: Thursday, June 05, 2008 4:33 PM
To: [hidden email]
Subject: Re: 2038 date limit

On Thu, Jun 05, 2008, Chris Kottaridis wrote:

> When trying to make a certificate for 30 years seems you run into the
> 2038 date limitation. Seems the code converts date to a signed int in
> seconds since 1970 and now that we are within 30 years of the 2038 limit
> we get hit by it. Using a date of (30 * 365) from now:
>
> notBefore=Mar25 19:33:38 2008 GMT
> notAfter=Feb 10 13:05:22 1902 GMT
>
> Clearly it wrapped around and subtracted 68 years from 1970 instead of
> adding 68 years.
>
> Is there a plan to remove this limitation ?
>
> I am seeing this on openssl-0.9.7m.
>

As has been mentioned this is caused by the time representation of the
underlying OS. OpenSSL relies on the OS routines to convert the time_t value
to appropriate date fields. If the time_t value wraps around you get the above
behaviour.

Changing this is would involve including independent date routines which don't
have this restriction. I did start on this some time ago but other higher
priority tasks (e.g. paid ones!) took over.

Note however that this doesn't affect OpenSSLs ability to *verify* date fields
in the far future. The technique used avoids time_t issues and it should
happily handle any date.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

Brant Thomsen
The C++ compiler in Microsoft's Visual Studio 2005 (and later) makes time_t
a 64-bit number when compiling 32-bit code.  Older compilers, such as Visual
C++ 6.0, make time_t a 32-bit number, which would cause year 2038 issues.

Brant Thomsen

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Jim Adams
Sent: Thursday, June 05, 2008 3:43 PM
To: [hidden email]
Subject: RE: 2038 date limit



What OS did you have this problem on?  I use Openssl 0.9.7m on Windows to
generate
certificates, and I was able to generate certs beyond 2038 with no problem.
I did not
experience a problem until I tried to generate one that lasted beyond 2106,
when the
entire 32-bit number overflows.  So Windows does not appear to have a
signed/unsigned
int problem such as you report.

Jim Adams


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Dr. Stephen Henson
Sent: Thursday, June 05, 2008 4:33 PM
To: [hidden email]
Subject: Re: 2038 date limit

On Thu, Jun 05, 2008, Chris Kottaridis wrote:

> When trying to make a certificate for 30 years seems you run into the
> 2038 date limitation. Seems the code converts date to a signed int in
> seconds since 1970 and now that we are within 30 years of the 2038 limit
> we get hit by it. Using a date of (30 * 365) from now:
>
> notBefore=Mar25 19:33:38 2008 GMT
> notAfter=Feb 10 13:05:22 1902 GMT
>
> Clearly it wrapped around and subtracted 68 years from 1970 instead of
> adding 68 years.
>
> Is there a plan to remove this limitation ?
>
> I am seeing this on openssl-0.9.7m.
>

As has been mentioned this is caused by the time representation of the
underlying OS. OpenSSL relies on the OS routines to convert the time_t value
to appropriate date fields. If the time_t value wraps around you get the
above
behaviour.

Changing this is would involve including independent date routines which
don't
have this restriction. I did start on this some time ago but other higher
priority tasks (e.g. paid ones!) took over.

Note however that this doesn't affect OpenSSLs ability to *verify* date
fields
in the far future. The technique used avoids time_t issues and it should
happily handle any date.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

Chris Kottaridis
In reply to this post by Jim Adams
It's a Linux 2.6.21 based system.

I think the issue comes into play here in x509.c:

x509_gmtime_adj(X509_get_notAfter(x),(long),60*60*24*days);

where days is an int and X509_gmtime_adj has it's second parameter
defined as a long.

and I believe int's and longs are 32 bits on this machine.

Thanks
    Chris Kottaridis    ([hidden email])
================================================

On Thu, 2008-06-05 at 17:42 -0400, Jim Adams wrote:

> What OS did you have this problem on?  I use Openssl 0.9.7m on Windows to generate
> certificates, and I was able to generate certs beyond 2038 with no problem.  I did not
> experience a problem until I tried to generate one that lasted beyond 2106, when the
> entire 32-bit number overflows.  So Windows does not appear to have a signed/unsigned
> int problem such as you report.
>
> Jim Adams
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Dr. Stephen Henson
> Sent: Thursday, June 05, 2008 4:33 PM
> To: [hidden email]
> Subject: Re: 2038 date limit
>
> On Thu, Jun 05, 2008, Chris Kottaridis wrote:
>
> > When trying to make a certificate for 30 years seems you run into the
> > 2038 date limitation. Seems the code converts date to a signed int in
> > seconds since 1970 and now that we are within 30 years of the 2038 limit
> > we get hit by it. Using a date of (30 * 365) from now:
> >
> > notBefore=Mar25 19:33:38 2008 GMT
> > notAfter=Feb 10 13:05:22 1902 GMT
> >
> > Clearly it wrapped around and subtracted 68 years from 1970 instead of
> > adding 68 years.
> >
> > Is there a plan to remove this limitation ?
> >
> > I am seeing this on openssl-0.9.7m.
> >
>
> As has been mentioned this is caused by the time representation of the
> underlying OS. OpenSSL relies on the OS routines to convert the time_t value
> to appropriate date fields. If the time_t value wraps around you get the above
> behaviour.
>
> Changing this is would involve including independent date routines which don't
> have this restriction. I did start on this some time ago but other higher
> priority tasks (e.g. paid ones!) took over.
>
> Note however that this doesn't affect OpenSSLs ability to *verify* date fields
> in the far future. The technique used avoids time_t issues and it should
> happily handle any date.
>
> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> OpenSSL project core developer and freelance consultant.
> Homepage: http://www.drh-consultancy.demon.co.uk
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Chris Kottaridis
In reply to this post by Dr. Stephen Henson

On Thu, 2008-06-05 at 22:32 +0200, Dr. Stephen Henson wrote:
> Changing this is would involve including independent date routines
> which don't
> have this restriction. I did start on this some time ago but other
> higher
> priority tasks (e.g. paid ones!) took over.
>

Right. From a quick perusal it seems that ASN1_GENERAILZEDTIME_set
actually ends up breaking the time into a tm structure and that is what
eventually gets stored:

BIO_snprintf(p,len,"%04d%02d%0d2%0d2%02d%02dZ", ts->tm_year + 1900,
ts->tm_mon+1,ts->tm_mday,ts->tm_hour,ts->tm_min,ts->tm_sec);

So, if there were routines that allowed you to add days to tm structures
(I assume days is the smallest unit of time used to generate
certificates), without having to convert to seconds, then we could avoid
the issue by doing all the math on a tm structure. I am sure it is
easier said then done.

Anyway, it sounds like it is currently generally accepted that on 32 bit
machines you can't generate certificates past 2038. That's really all I
was looking for here is that it's just generally accepted to be a
limitation.

Thanks
    Chris Kottaridis    ([hidden email])

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Jason Dusek
In reply to this post by Chris Kottaridis
  It would be nice if we could easily specify the epoch for
  certificate expiration.

--
_jsn
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Michael Sierchio-2
In reply to this post by Brant Thomsen
Brant Thomsen wrote:
> The C++ compiler in Microsoft's Visual Studio 2005 (and later) makes time_t
> a 64-bit number when compiling 32-bit code.  Older compilers, such as Visual
> C++ 6.0, make time_t a 32-bit number, which would cause year 2038 issues.

I'd very much like to see TAI64 adopted where one second granularity
is required (sufficient for all dates in the past and future until
the EOL of the universe), and TAI64n (requiring 64 + 30 bits in some
representation) for nanosecond accuracy.

Dan Bernstein's libtai is a good starting point.  Many things
will have to change, including the ntp protocol, but a
more rational representation for time values will have plenty of
good side-effects.

- M
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

JoelKatz
In reply to this post by Dr. Stephen Henson

> Changing this is would involve including independent date
> routines which don't
> have this restriction. I did start on this some time ago but other higher
> priority tasks (e.g. paid ones!) took over.

I've got 64-bit date/time routines that are good out to 2270 that work fine
on 32-bit architectures. Would the following routines be sufficient:

1) All routines are based on a uint64_t to hold the seconds since the epoch.
So you can still easily convert to/from time_t for in-range values.

2) Get day, month, year, hour, minute, and second from a uint64_t seconds
since the epoch value. Or, convert a uint64_t to a struct tm (as either UTC
or local time) and you can extract whichever of these elements are needed.

3) Convert to time_t, which returns an error if the value is out of range.

4) Format a uint64_t in UTC time using a strftime like format. Format in
local time using a strftime like format.

5) Convert a struct tm in either local or UTC time to a 64-bit 'seconds
since epoch' value.

To add a second or a week or compare two times, normal integer routines can
be used. All routines, again, are believed valid from the epoch to 2270. (At
worst, they might somehow bungle leap year issues, I guess.)

The way these routines work is for out-of-range dates, they fudge them into
range (using an offset that keeps all time rules the same), use the system
routines, and then fudge them back to the starting range.

For example (this is not quite the actual code):

#define ULL(x) x##ULL
#define SSE(x,y) if(secs>=x) { secs-=x; add_years=y; }
#define DAYS(x) (ULL(x)*(24*60*60))
...
// adjust to range
 if(secs<ULL(0x7fffffff)) { add_years=0; }
 else SSE(DAYS(87669), 240) else SSE(DAYS(80353), 220)
 else SSE(DAYS(73049), 200) else SSE(DAYS(65744), 180)
 else SSE(DAYS(58439), 160) else SSE(DAYS(51134), 140)
 else SSE(DAYS(43830), 120) else SSE(DAYS(36525), 100)
 else SSE(DAYS(29220), 80)  else SSE(DAYS(23376), 64)
...
// bring it back in range
 t.tm_year+=add_years;

If this code would be helpful, I could clean it up and separate it from some
other code it's entangled with. I don't have the time to work on integrating
it with OpenSSL though. (Though if there's interest but not resources, I
might be able to task someone else with doing it.)

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

sunilv
Hello

Could you unsubscribe me from this mailing list.

Regards
Sunil.

________________________________

From: [hidden email] on behalf of David Schwartz
Sent: Fri 6/6/2008 10:09 AM
To: [hidden email]
Subject: RE: 2038 date limit




> Changing this is would involve including independent date
> routines which don't
> have this restriction. I did start on this some time ago but other higher
> priority tasks (e.g. paid ones!) took over.

I've got 64-bit date/time routines that are good out to 2270 that work fine
on 32-bit architectures. Would the following routines be sufficient:

1) All routines are based on a uint64_t to hold the seconds since the epoch.
So you can still easily convert to/from time_t for in-range values.

2) Get day, month, year, hour, minute, and second from a uint64_t seconds
since the epoch value. Or, convert a uint64_t to a struct tm (as either UTC
or local time) and you can extract whichever of these elements are needed.

3) Convert to time_t, which returns an error if the value is out of range.

4) Format a uint64_t in UTC time using a strftime like format. Format in
local time using a strftime like format.

5) Convert a struct tm in either local or UTC time to a 64-bit 'seconds
since epoch' value.

To add a second or a week or compare two times, normal integer routines can
be used. All routines, again, are believed valid from the epoch to 2270. (At
worst, they might somehow bungle leap year issues, I guess.)

The way these routines work is for out-of-range dates, they fudge them into
range (using an offset that keeps all time rules the same), use the system
routines, and then fudge them back to the starting range.

For example (this is not quite the actual code):

#define ULL(x) x##ULL
#define SSE(x,y) if(secs>=x) { secs-=x; add_years=y; }
#define DAYS(x) (ULL(x)*(24*60*60))
...
// adjust to range
 if(secs<ULL(0x7fffffff)) { add_years=0; }
 else SSE(DAYS(87669), 240) else SSE(DAYS(80353), 220)
 else SSE(DAYS(73049), 200) else SSE(DAYS(65744), 180)
 else SSE(DAYS(58439), 160) else SSE(DAYS(51134), 140)
 else SSE(DAYS(43830), 120) else SSE(DAYS(36525), 100)
 else SSE(DAYS(29220), 80)  else SSE(DAYS(23376), 64)
...
// bring it back in range
 t.tm_year+=add_years;

If this code would be helpful, I could clean it up and separate it from some
other code it's entangled with. I don't have the time to work on integrating
it with OpenSSL though. (Though if there's interest but not resources, I
might be able to task someone else with doing it.)

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org <http://www.openssl.org/>
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com

winmail.dat (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: 2038 date limit

Mark-62
In reply to this post by Eljas Alakulppi
> > Is there a plan to circumvent the limit, as opposed to just
> saying stay
> > within 2038 ?
> Afaik, the only current solution is to switch to 64bit openssl.

On a lot of platforms there are ways to use 64 bit time_t even on
32 bit OSs.  This would look like a good interim solution IMHO.

Mark.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 2038 date limit

Dr. Stephen Henson
In reply to this post by JoelKatz
On Thu, Jun 05, 2008, David Schwartz wrote:

>
> 1) All routines are based on a uint64_t to hold the seconds since the epoch.
> So you can still easily convert to/from time_t for in-range values.
>

Well there has been a problem on some platforms in the past which don't have a
64 bit integer type. The pqueue code for example was changed as a result.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
12