tar2rpm: Build Date is far in the future

[steffenbusch]

The rpm created by tar2rpm contains a "Build Date" that is far in the future.
Steps to reproduce:

kali@kali:~/go$ date
Wed 08 Jul 2020 04:02:49 PM EDT

kali@kali:~/go$ ./tar2rpm -file /tmp/example.rpm -name "Example" -version "1.0" /tmp/input.tar

kali@kali:~/go$ rpm -qip /tmp/example.rpm

Name        : Example
Epoch       : 0
Version     : 1.0
Release     : 
Architecture: noarch
Install Date: (not installed)
Group       : 
Size        : 727851
License     : 
Signature   : (none)
Source RPM  : Example-1.0.src.rpm
Build Date  : Sun 13 Jul 2042 09:04:00 PM EDT
Build Host  : 
Relocations : (not relocatable)
Packager    : 
Vendor      : 
URL         : 
Summary     : 
Description :

Expectation:
The "Build Date:" line of the rpm query should contain something like "Wed 08 Jul 2020 04:02:49 PM EDT", but it's always "Sun 13 Jul 2042 09:04:00 PM EDT" even on subsequent delayed rebuilds of the rpm.

[jarondl]

The problem with embedding the actual build date, is that it makes the build non-reproducible and non-cachable. The tag is optional, and I expanded about why I don't like build dates in the discussion of #33, where the dates were added due to non-compliant consumers.

The reason you see 2042 is rather silly. In #33 we used signed int32, but apparently if you truncate the sign of the int64 golang zero value of time.Time which is supposed to be in the year 1, with uint32, you get 2042.
https://play.golang.org/p/akDPNe6tLZb

I don't think we should use the actual date. We should fix the uint32 thing.

If you have an actual use case for having the real date, we can accept it as another flag, say --build_timestamp with the unix timestamp of the build. But only if this is something you need, and not just something you've noticed.

[steffenbusch]

Thanks for your swift feedback.
I definitely have a use case for this (especially to avoid repeating clients from asking about that bogus timestamp) and would really appreciate if the -build-timestamp flag like you suggested could be added.

[jarondl]

Can you check #46 and see if it fixes the bug?

[steffenbusch]

Can you check #46 and see if it fixes the bug?

Yes, thanks a lot. This fixes the issue for me:

Testcase 1: Run tar2rpm as previously and verify that Build Date does not contain this weird year 2042 date:

kali@kali:~/tmp$ ./tar2rpm -file /tmp/example.rpm -name "Example" -version "1.0" --build_time "$(date +%s)" /tmp/input.tar && rpm -qip /tmp/example.rpm
Name        : Example
Epoch       : 0
Version     : 1.0
Release     :
Architecture: noarch
Install Date: (not installed)
Group       :
Size        : 3582239
License     :
Signature   : (none)
Source RPM  : Example-1.0.src.rpm
Build Date  : (none)
Build Host  :
Relocations : (not relocatable)
Packager    :
Vendor      :
URL         :
Summary     :
Description :

Result: As expected. The Build Date of "(none)" is reasonable.

Testcase 2: Run tar2rpm with the new command line switch --build_time with argument of current unix timestamp from /bin/date

kali@kali:~/tmp$ ./tar2rpm -file /tmp/example.rpm -name "Example" -version "1.0" --build_time "$(date +%s)" /tmp/input.tar && rpm -qip /tmp/example.rpm
Name        : Example
Epoch       : 0
Version     : 1.0
Release     :
Architecture: noarch
Install Date: (not installed)
Group       :
Size        : 3582239
License     :
Signature   : (none)
Source RPM  : Example-1.0.src.rpm
Build Date  : Fr 17 Jul 2020 14:43:57 CEST
Build Host  :
Relocations : (not relocatable)
Packager    :
Vendor      :
URL         :
Summary     :
Description :

Result: As expected. The Build Date contains the Timestamp when the rpm was created with tar2rpm.

Thanks a lot!