X509_cmp_time fails for dates that don't fit in time_t

[fancycode]

In de5a7bf#diff-c72c45bb1891a4148a352b678fe463d4 X509_cmp_time has changed in that the string must be representable by time_t.

This causes it to fail for large dates on 32bit platforms (tested on Ubuntu) where time_t is 32bit causing certificates that have a really far future expiration (e.g. 100 years from now) to no longer verify successfully.

Such certificates verify with OpenSSL/BoringSSL.

[bob-beck]

There is no reason for a modern 32 bit platform to have a 32 bit time_t - if it is your operating system is going to be badly broken on dates in the near future - i.e. after January 18, 2038

In a nutshell, OpenSSL is failing defensively, because your operating system is fundamentally broken for these dates, and you will very likely have security problems
dealing with and accepting and manipulating such dates.. Really, this is an issue that
the underlying operating system needs to fix - to avoid many other problems (even if we accept the certificate).

"Programs that work with future dates will begin to run into problems sooner; for example a program that works with dates 20 years in the future will have to be fixed no later than 2018." : https://en.wikipedia.org/wiki/Year_2038_problem

[bob-beck]

And in case you're wondering, I'm of an age where some jerk might end up putting some embedable linux 32 bit internet-of-shite thing in my chest as a pacemaker or something before Jan 19 2038.. I'm not going to get killed by a crappy linux freaking out then because I didn't to my darndest to get the ecosystem to fix it's problems. I want to die from my own foolish excesses.

[fancycode]

Thanks for your delightful response. Lets hope you (or me for that matter) will never need a pacemaker ;-)

Unfortunately the software I wanted to build against LibreSSL is running with Ubuntu Trusty on armhf which only has a 32bit time_t - I guess I'll have to stick with OpenSSL/BoringSSL for now then.

Anyway, thanks for your feedback and sorry for bothering you.

[bob-beck]

Yes, indeed you'll have to stick with that, and/or be able to run the linux
x32 ABI environment on it (although I don't think you can for that). Since
the focus of 32 bit linux is "backward compatibility" I think you will need
to stick to something
backward on that - sorry ;)

On Wed, Jul 27, 2016 at 4:40 PM, Joachim Bauch notifications@github.com
wrote:

Thanks for your delightful response. Lets hope you (or me for that matter)
will never need a pacemaker ;-)

Unfortunately the software I wanted to build against LibreSSL is running
with Ubuntu Trusty on armhf which only has a 32bit time_t - I guess I'll
have to stick with OpenSSL/BoringSSL for now then.

Anyway, thanks for your feedback and sorry for bothering you.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#66 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHv2dalKnoZ6I4o7VKs0upPt1Mqnlgz0ks5qZ95ZgaJpZM4JU6Cr
.

[leahneukirchen]

AFAICS, this is being worked around in 362ffef

[4a6f656c]

@chneukirchen - correct, the notafter date is now clamped to 2038 in the case of a 32-bit time_t.