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
Hello
Could you unsubscribe me from this mailing list.
Regards
Sunil.
From: [EMAIL PROTECTED] on behalf of David Schwartz
Sent: Fri 6/6/2008 10:09 AM
To: openssl-users@openssl.org
Subject: RE: 2038 date limit
Changing this is would involve including
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.
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.
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
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
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
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: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: openssl-users@openssl.org
Sent: Thursday, June 5, 2008 8:22:09 PM
Subject: Re: 2038 date limit
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
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
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
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
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
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
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
Windows does not appear to have a
signed/unsigned
int problem such as you report.
Jim Adams
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen
Henson
Sent: Thursday, June 05, 2008 4:33 PM
To: openssl-users@openssl.org
Subject: Re: 2038 date limit
]
[mailto:[EMAIL PROTECTED] Behalf Of Jim Adams
Sent: Thursday, June 05, 2008 3:43 PM
To: openssl-users@openssl.org
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
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen
Henson
Sent: Thursday, June 05, 2008 4:33 PM
To: openssl-users@openssl.org
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
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
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
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
21 matches
Mail list logo
