On Aug 26, 2017, at 18:52, Bob Beck wrote:
With the new define (SMALL_TIME_T) enabled, a 32-bit time_t build
using "openssl s_client -connect" can successfully connect to a
server
and verify its certificate chain when one or more notAfter dates
after
2038 are present.
However, using "nc -c
>
> With the new define (SMALL_TIME_T) enabled, a 32-bit time_t build
> using "openssl s_client -connect" can successfully connect to a server
> and verify its certificate chain when one or more notAfter dates after
> 2038 are present.
>
> However, using "nc -c" fails to connect to the same
Thank you.
I have applied the change to the latest LibreSSL portable tarball and
tested it.
With the new define (SMALL_TIME_T) enabled, a 32-bit time_t build
using "openssl s_client -connect" can successfully connect to a server
and verify its certificate chain when one or more notAfter dat
https://github.com/openbsd/src/commit/b943944faeecf3a978bf3f57df1b35335ffecbec
On Tue, Jul 11, 2017 at 4:23 AM, Stuart Henderson
wrote:
> On 2017/07/11 01:55, Kyle J. McKay wrote:
> > 2) 32-bit systems are going to be around for many years still; 32-bit ARM
> > platforms are everywhere
> ..
> >
Hi,
I have built embedded systems that have run 20 years with no update - but I
doubt they are common.
More of an issue is archived data. I have read data 30 years old, and may
well do so again. While
I think the answer is "human readable date formats" The Americans have
scuppered that with M-D-Y
On 2017/07/11 01:55, Kyle J. McKay wrote:
> 2) 32-bit systems are going to be around for many years still; 32-bit ARM
> platforms are everywhere
..
> 4) 32-bit time_t has potentially still got over 20 years of life left in it
Yes. The gamble is whether 32-bit systems will still be around then.
I d
On Jul 5, 2017, at 22:30, Bob Beck wrote:
On Thu, May 18, 2017 at 7:31 AM, Kyle J. McKay
wrote:
RFC 5280 section 4.1.2.5 states:
To indicate that a certificate has no well-defined expiration
date,
the notAfter SHOULD be assigned the GeneralizedTime value of
1231235959Z.
T
On Thu, May 18, 2017 at 7:31 AM, Kyle J. McKay wrote:
> RFC 5280 section 4.1.2.5 states:
>
> To indicate that a certificate has no well-defined expiration date,
> the notAfter SHOULD be assigned the GeneralizedTime value of
> 1231235959Z.
>
>
True enough.
> Unfortunately, if si
RFC 5280 section 4.1.2.5 states:
To indicate that a certificate has no well-defined expiration date,
the notAfter SHOULD be assigned the GeneralizedTime value of
1231235959Z.
Unfortunately, if sizeof(time_t) == 4, -12-31T23:59:59Z cannot be
represented as a time_t value causin
