SDE and Y2038

[Bernhard M. Wiedemann]

Hi,

in preparation for our summit next week, I want to share two related 
topics I would like to discuss there.

====

1.1:
One is the Year-2038-Problem/Y2K38/Epochalypse
  - about an int overflowing after 2038-01-19 .
It affects us in two ways:
   Firstly, I stumbled upon this, when double-building to verify 
reproducibility, because I argued, our software will be used for 15+ 
years, unchanged in some environments, so why not extend the common 13 
month offset to +15y.
This brought me into 2038 at some point and made me realize how much 
current software is broken, even on x86_64.
Plenty python module tests failed, but some of it is just because they 
have a culture of high test-coverage. E.g. python tests uncovered issues 
in mariadb and taskwarrior.

1.2:
The second way how this affects us is via SOURCE_DATE_EPOCH, which 
nominally is a string with digits, but has to be converted to an int. 
And we might have naively used atoi or atol at some point for that 
conversion.
Even atoll is problematic for portability reasons.

2038 might seem far away, but when you do the math, it is just 11y and 4 
months away.
While the (32-bit) Raspberry PI 1 was released in 2012 - that was 14y 
ago and many are probably still in use.

====

The second topic is about discussing some improvements to our SDE spec
https://reproducible-builds.org/specs/source-date-epoch/

2.1:
currently it says

>  If the value is malformed, the build process SHOULD exit with a non-zero error code. 

Such error handling causes overly complex patches for handling 
exceptional cases that should never happen. And ugly patches are less 
likely to be accepted by upstreams.

I would like to see it changed to 'MAY' .
Or we could just declare behaviour as undefined in that case.
Or we add 'implementations MAY ignore a SOURCE_DATE_EPOCH=foo'


Other open questions are:

2.2:
is -5 valid?
One old 2018 example in the history of _docs/source-date-epoch.md used 
strtoull, so it would not be properly handled there. OTOH, time_t would 
be a signed int64_t

2.3:
A related question:
Is 0 a valid timestamp for SDE?
That would make some coding more complex in some languages - especially 
those, that don't have 'undef'

So we could declare '1' as the lowest valid value for SDE.
OTOH, rejecting 0, can break some current usages.
So maybe we explicitly allow 0 and review all old patches for places 
that need to be changed to handle a SDE=0.
For 1.2 we can look for atoi/atol at the same time.

The spec makes some assumptions there:
> It SHOULD be set to the last modification time of the source

> One can reasonably assume that all source timestamps are before SOURCE_DATE_EPOCH


2.4:
Is it OK to use as a flag to mean "want reproducible output" ?
I have been doing that in several places, because it is the only 
reliable indication we have atm.
E.g. if SDE is set, we normalize hostname+username

In some rpm specfiles, I started using a
%if 0%{?want_reproducible_builds}
e.g. to skip profile-guided-optimizations,
but that only works in the rpm-based world, not upstream.


Feel free to reply to the list or to me directly, so we are better 
prepared for that discussion.


Ciao
Bernhard M.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260919/f6dfea3c/attachment.sig>