> 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
>
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
> > 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
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 includ
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 o
> 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 archit
It would be nice if we could easily specify the epoch for
certificate expiration.
--
_jsn
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@op
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 perusa
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
>
> On Thu, Jun 05, 2008, Chris Kot
ECTED]
[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 pr
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
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
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
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 ep
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 t
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
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
>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 w
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
S
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 dat
20 matches
Mail list logo
