On Saturday 10 February 2018 11:09:04 Kevin Chadwick wrote: > On Sat, 10 Feb 2018 16:24:38 +1100 > > > > Just in case some libressl dev doesn't want read the full thread in > > > the Alpine list, they want also a workaround for the lack of time_t > > > for 32bits platforms on Linux. > > > > We've already addressed this - a notafter that exceeds 2038 is > > clamped to 2038 on system that only has 32-bit time_t - see r1.65 of > > src/lib/libcrypto/x509/x509_vfy.c: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c > > .diff?r1=1.64&r2=1.65 > > Natanael had already found that but William says TAI64n is required to > be conformant. Perhaps you will understand where he is coming > from or whether he has an unspoken agenda? His original email did not > seem to be a fair representation of facts though.
Conformant with what exactly? I do not recall seeing anything regarding TAI64N in TLS/X509 RFCs, where everything is handled in ASN.1 GENERALIZEDTIME or UTCTIME. > I can't see how this (assuming this is the TAI64N in question) helps but > I assume I am missing something. > > https://cr.yp.to/daemontools/tai64n.html > > "Beware that most gettimeofday implementations are not Y2038-compliant."
