-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
tests fail after 2027-06-23 #6978
Comments
Thank you for reporting this! The build of the library and the test programs should be reproducible. (Do please let us know if it isn"t — we are not currently testing this in our CI.) However, the tests are unavoidably not fully reproducible because there are dates in the test data. We cannot generate the test data based on the current date (it"s far too complex), and we cannot always force a date when testing (it"s not possible in all environments). Goal of this issue: fix the 2023 expiry. We"ll test manually. I"ve filed a separate issue to address the requirement of having tests pass 16 years in the future. |
The list of test cases that will fail on 07 August 2023 in the From
From
From
Many of them are copies of the same few certificates (one RSA and one ECC?) used in different context. But quite a few are manually modified to exercise error detection in parsers. |
For other test-suites we created certs that expire in 2999, because these are not meant to expire (unlike regular production-grade certification). Would that work for you? gnutls" |
Changing to make our certs expire in 2999 would be great if it works. I don"t know if it"s possible: I don"t know if everything we"re using supports dates that far in the future. (We don"t even have tests for Y2038!) This includes interop tests with old versions of OpenSSL and GnuTLS. The difficulty for us with updating certificates is that since we"re an X.509 library, we have a lot of negative test cases, many of them crafted by manually tweaking some nominal data. Updating the files containing nominal data is only the tip of the iceberg. |
An alternative solution could be to provide a date to the validation functions that is used instead of the current date. A date-override could even have advantages in production builds. E.g. when you run as non-root on a system with incorrect system time and still want SSL validation. |
Hi. What is the status of the fix for this issue? Only one week left until 2023-08-07 |
We"ve regenerated all the test certificates that expired in 2023. We"re keeping this issue open because we"re still working on an alert mechanism and on regenerating certificates that will expire in the next few years. |
For the sake of continuing to have passing tests in third-party packages that ship Mbed TLS such as Linux distributions and BSP, we"re going to make official releases today or tomorrow (right now we"re making some final preparations):
|
Thanks a lot. |
As of 2.28.5 and 3.5.0, the next certificate expiry is on 2027-06-23 ( |
Summary
While working on reproducible builds for openSUSE, I found that in our
mbedtls-2.28.2
package,similar to #2357 , SSL tests start to fail after 2023-08-07.
System information
Mbed TLS version (number or commit id): 2.28.2
Operating system and version: openSUSE-Tumbleweed-20230126
Configuration (if not default, please attach
mbedtls_config.h
):Compiler and options (if you used a pre-built binary, please indicate how you obtained it): https://code.opensuse.org/package/mbedtls/blob/master/f/mbedtls.spec#_97
Additional environment information:
Expected behavior
Tests should continue to pass at least 16 years into the future.
Actual behavior
Steps to reproduce
On Debian or openSUSE do:
or set the system clock or use libfaketime to run the tests.
Additional information
tests/data_files/test-ca2_cat-present-future.crt
has expiry ofAug 7 09:17:03 2023 GMT
and many more expire in September.Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future.
The usual offset is +16 years, because that is how long I expect some software will be used in some places.
This showed up failing tests in our package build.
See https://reproducible-builds.org/ for why this matters.
The text was updated successfully, but these errors were encountered: