[reproducible builds] timestamp varies in buildah/internal/mkcw

[bmwiedemann]

Description

While working on reproducible builds for openSUSE, I found that our buildah 1.33.1 package varies across builds.

buildah-1.31.2 still built reproducibly on 2023-08-14

Steps to reproduce the issue:

1. build buildah in two fresh VMs with cd ~/rpmbuild/BUILD/buildah-1.33.1 && SOURCE_DATE_EPOCH=1 GOPATH=$HOME/go GOFLAGS=-buildmode=pie make GIT_COMMIT=unknown buildah && md5sum bin/buildah

Something within the system records the timestamp, so it possible to get two bit-identical within the same VM, but not in two different VMs.

Describe the results you received:
results varied in a UNIX epoch timestamp at offset 4 in an ELF section labeled github.com/containers/buildah/internal/mkcw..gobytes.1 -- visible in objdump -D --disassemble=github.com/containers/buildah/internal/mkcw..gobytes.1 bin/buildah |grep -A5 gobytes.1.:

Describe the results you expected:
it should be possible to receive bit-identical build-results

Output of rpm -q buildah or apt list buildah:

buildah-1.33.1

Output of buildah version:

Version:         1.33.1
Go Version:      go1.21.4
Image Spec:      1.1.0-rc.5
Runtime Spec:    1.1.0
CNI Spec:        1.0.0
libcni Version:  v1.1.2
image Version:   5.29.0
Git Commit:      unknown
Built:           Thu Jan  1 00:00:01 1970
OS/Arch:         linux/amd64
BuildPlatform:   linux/amd64

Output of cat /etc/*release:

openSUSE Tumbleweed 20231122
(don't have exact output)

[rhatdan]

@nalind PTAL

[nalind]

Based on conversations elsewhere, I think this is as simple as using -n when we compress the statically-built dummy entrypoint binary. @bmwiedemann, is there any chance you're able to grab the tip of the pull request and check if it fixes the problem you're seeing?

[bmwiedemann]

Yes, gzip -n helps.