-
-
Notifications
You must be signed in to change notification settings - Fork 10.5k
y2038: tests should not be failing if system date is set to after 2038 #21671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Ping, please. |
For anything that's in test/certs, it should be quite easy, just do this: $ cd test/certs
$ ./setup.sh Although, I'm not sure that it should be necessary, as the expiry has been set to 100 years forward, and the files in there weren't generated that long ago... Regarding |
Can you provide verbose test output for the sslapi test failure?
|
We package the tests into the target image, and use ./test/run_tests.pl directly. With that, I get:
If that's not verbose enough, I can try again with extra verbosity if you tell me how. |
To test the readiness of Yocto stack for Y2038 we run qemu virtual machines with RTC set to some day in 2040. This causes a few of openssl's tests to fail on both 32 bit and 64 bit systems: the reason is that test data, certificates in particular, seem to set their expiry date to 2035 or so.
I would propose to set the expiry date to far enough in the future that it won't have to be tweaked in our lifetimes: this way real Y2038 issues in openssl (or in things it depends on) can be exposed and fixed (it's well possible there are none, but that needs confirmation too).
Failures seen:
If there's agreement on this, I can prepare the patch, but I need guidance as to how to regenerate the data correctly (there seem to be no way of doing it with a script from metadata, rather the data is simply stored in git).
The text was updated successfully, but these errors were encountered: