Page History

The term "Reproducible Builds" refers to making sure the build process for various artifacts is so deterministic that building the same sources twice (by different people) results in a bit-by-bit identical artifact. You can read more about it on https://reproducible-builds.org/.

One of the advantages of Reproducible Builds is that, when those two builds happen on independently-managed infrastructureinfrastructures, validating that both environments produce the same bit-by-bit artifact improves the confidence that no backdoor or other malware was injected into the artifact due to a compromise of the infrastructure.

...

It is good practice for all artifacts released by the ASF to be reproducible.

For projects that want to build and sign artifacts on CI, Reproducible Builds are are required. This means:

• your builds must be deterministic enough that independent builds produce bit-by-bit identical artifacts,
• you have documented how and when artifacts are actually independently rebuilt and verified in your release process,
• you follow this process in practice for each release.

Ecosystem-specific notes

See below for any ecosystem-specific notes that could be helpful for other projects to make their builds reproducible.

If you have additional input to share, feel free to edit this wiki page. If you have questions or want to discuss approaches, you can use the the security-discuss mailinglist mailing-list or Slack channel.

Archive/artifact contents

...

You can read more about reproducible build support in Flit reproducible build docs and Hatch reproducible build docs.

Container image

TBD

Few references: FOSDEM 2023,  https://github.com/reproducible-containers, https://arxiv.org/abs/2602.17678

Helm package

The helm package command from Helm versions before 4.0.0 cannot produce reproducible archives.

Since Helm version 4.0.0, it is possible to produce reproducible archives, even with the --sign option. The package archive entries get a constant uid/gid and fixed POSIX permissions. The file modification time is set to the source files' modification time.
Consider setting a constant file modification time, for example using find $PACKAGE_CONTENTS_DIRECTORY -exec touch -d "2000-01-01 00:00:00" {} +

Preparing reproducible source .tar.gz packages

If you prepare source-tarball, or another .tar.gz package you can use scripts similar to this one - which takes the same source_date_epoch and repacks the .tar.gz file to be reproducible. There are however few gotchas:

...