make packageworld/packagekernel create tarballs with unspecified order. Two successive runs will produce tarballs with different checksums, even though the included files are the same. Ordering the files within the tarball would improve reproducible builds.
GNU tar supports a --sort option (--sort=name); bsdtar has no such option yet. There is an old proof-of-concept patch with some commentary: https://github.com/libarchive/libarchive/issues/602. We'll have to figure out how to add this functionality to bsdtar.
We can probably use `find | sort | tar -c -nT-` as an alternative to adding functionality to bsdtar.
(In reply to Colin Percival from comment #2) > We can probably use `find | sort | tar -c -nT-` as an alternative to adding > functionality to bsdtar. That's a good suggestion and looks like a suitable interim solution. I'd still want the functionality in bsdtar though.
Yep, I was playing with find sort last night, and got that piece working. It looks like this: find -s . > ${WORLDTMP}/package-${dist}-files; \ ${TAR_CMD} cnvf - --exclude usr/lib/debug -T ${WORLDTMP}/package-${dist}-files | \ mtimes are another source of non-determinism. https://download.freebsd.org/releases/amd64/14.2-RELEASE/kernel.txz has 338 unique timestamps in it. It wasn't clear to me how to adjust those. I put a `touch -A` in the places I thought it should go, but I didn't get that working - and don't know if that would be desirable anyway. What I can do for now is determine what transformations are needed to make two tarballs equivalent. I suspect it's only the order and times - I can't think of what else there would be. But I can confirm that and report back, and then figure out what comes next.
GNU tar also supports --mtime to address that issue. The reproducible builds project has info on archive metadata in general: https://reproducible-builds.org/docs/archives/
I'd suggest constructing an mtree file (aka METALOG) and then passing that to the tarball creation. That will let you specify the mtime you want.
I wonder if we should (at least in the REPRODUCIBLE_BUILDS case) be inserting a fixed mtime into a METALOG regardless. We should not be relying on file system ownership or permissions for packaging anyway since we should not need root to make packages. (The word "should" may be carrying a long of load in that statement...)
Okay I have a proof of concept that I can put on Phab. I think it's appropriate to put WIP on Phab to get feedback, and iterate - correct?
I moved the work into https://github.com/freebsd/freebsd-src/pull/1550 as a series of smaller commits There's one more source of non-determinism that I'm seeing right now: usr/share/man/mandoc.db. All of my builds end up with it as a different size.
https://github.com/freebsd/freebsd-src/pull/1550 produces a consistent build when run on amd64, as root - tested on 14.2 ZFS, 14.1 ZFS, 13.4 UFS.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=950401d21e33df7ac63ef1d2316a18f09ffbaabe commit 950401d21e33df7ac63ef1d2316a18f09ffbaabe Author: Pat Maddox <pat@patmaddox.com> AuthorDate: 2024-12-13 21:15:45 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2024-12-16 22:58:42 +0000 release: Sort etcupdate entries for base metalog Supports reproducible builds. PR: 283214 Reviewed-by: emaste Signed-off-by: Pat Maddox <pat@patmaddox.com> release/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=58610d1e0fbbd1a49927559ee3970d8e4594cc86 commit 58610d1e0fbbd1a49927559ee3970d8e4594cc86 Author: Pat Maddox <pat@patmaddox.com> AuthorDate: 2024-12-13 19:57:30 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2025-01-06 17:56:30 +0000 build: Sort distributekernel METALOG when using -DNO_ROOT The metalog is produced by install -M, which is not inherently sorted. This results in non-deterministic file ordering in kernel.txz. Order the files in kernel.txz to support reproducible builds. PR: 283214 Reviewed by: emaste Signed-off-by: Pat Maddox <pat@patmaddox.com> Makefile.inc1 | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)
^Triage: assign to committer. Note that the Pull Request is still open.
> Note that the Pull Request is still open. Yes, portions of the pull request have been merged, but there are still a few issues open