toolchain/52443: Reproducible builds don't work on 64bit Linux

[aymericvincent%free.fr@localhost]

>Number:         52443
>Category:       toolchain
>Synopsis:       Reproducible builds don't work on 64bit Linux
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 30 14:50:00 +0000 2017
>Originator:     Aymeric Vincent
>Release:        -current, -8
>Organization:
>Environment:
Linux 4.12.4 x86_64

>Description:
Option "-P" (reproducible builds) of src/build.sh is broken on Linux.

usr.bin/cvslatest/cvslatest.c makes use of strptime(3), but strptime() requires _XOPEN_SOURCE to be defined under Linux in order to get its prototype.

However, given that the code for the function is in libc anyway, strptime() will be called and treated as if it returned an int when it actually returns a pointer. The pointer is truncated to 32bits, dereferenced, and nbcvslatest dumps core.


A much less important problem is also that the timestamp is printed by src/build.sh at the end of the build, using "date -r" which doesn't do the same thing at all. "date -d @TS" works on both NetBSD and Linux, but from looking at the date(1) man page of FreeBSD it shouldn't work on FreeBSD.

>How-To-Repeat:

Try to build.sh -P under a 64bit Linux. See it fail and make nbcvslatest dump core.

It is also probably broken on any non-NetBSD LP64 OS which has strict feature testing header files.

>Fix:
A workaround for the problem is to

#define _XOPEN_SOURCE

at the beginning of usr.bin/cvslatest/cvslatest.c, but it looks wrong because it makes build.sh less OS independant. Possibly a better solution would be to import strptime.c into src/tools/compat.


As for the timestamp printing problem, it could make sense to check which OS we are running on to select an invocation of date. A simpler solution would be to print the timestamp untouched, as a number of seconds since Epoch.