Suggestion: Run rebuild test and/or autopkgtest with a future date to detect timebombs.
I hope this list is an appropriate place to reach people who handle
rebuild tests. If not can you suggest a place that is.
Some code has "timebombs", that is code that works correctly on systems
with the system clock up to a certain date but then will fail with
values of the system clock beyond that date. There are several possible
causes incuding:
1: explicit comparisons of some date in the code to the current date
(e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775044 ).
2: ssl certificate expiry (e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775044 )
3: issues related to time representation (don't have any debian examples
but well known cases include Y2K and Y2038)
Timebombs can happen either at build time, runtime or both depending on
the affected code. Obviously we can't detect all runtime cases but it
would seem sensible to run rebuild tests (to detect build time cases
including runtime cases caught by build time test suites) and
autopkgtest tests (to detect more runtime cases) with a date in the future.
Then theres the question of how far in the future. Go too far in the
future and you will waste a lot of time on certifcate expiry (it's
common to use a 10 year expiry for root certs afaict) and possiblly date
representation problems that are beyond the useful life of the release.
Not far enough in the future and you miss things that will come up.
I think for jessie ~6 years from now is a reasonable target for timebomb
elimination. This is based on the fact that the current plan for squeeze
lts is 5 years from release.
Someone on IRC also suggested using Febuary 29th as the test date to
further stress date related code. Maybe Febuary 29th 2020 is a
reasonable test date.
Reply to: