You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
If a package is re-built with the same contents, but at two different times, the two packages will have binary differences because of the embedded timestamps.
I need to be able to build packages in a way that is completely reproducible, so that the same inputs gives me byte-for-byte the same package output.
For the files I'm packaging, I can set the mtime via the config file, or by changing the mtime on the file tree before running nfpm. However, there is no current mechanism for me to manage the timestamps generated within nFPM.
Describe the solution you'd like
Make the package build process reproducible by using the standard SOURCE_DATE_EPOCH env var (if available) instead of using time.Now().
More specifically, I think we can replace all of the time.Now() occurrences with one value calculated early on. Then, adjust that calculation to use SOURCE_DATE_EPOCH instead, if available.
We can probably also use this build_date for a default mtime of package contents, but that is NOT what this issue is about. This issue is about controlling the current usages of time.Now(). These are the current instances that github search shows: https://github.com/search?q=repo%3Agoreleaser%2Fnfpm+time.now&type=code
* feat: allow to set a build date
defaults to $SOURCE_DATE_EPOCH
closes#744closes#734
Signed-off-by: Carlos Alexandro Becker <[email protected]>
* fix: rename to mtime
* docs: fix systemd note
closes#739
* fix: improve arch packager
* fix: arch test
Signed-off-by: Carlos Alexandro Becker <[email protected]>
* fix: improve apk packager
* fix: improve deb special files
* fix: reuse keys func
* fix: deps
Signed-off-by: Carlos Alexandro Becker <[email protected]>
---------
Signed-off-by: Carlos Alexandro Becker <[email protected]>
Is your feature request related to a problem? Please describe.
If a package is re-built with the same contents, but at two different times, the two packages will have binary differences because of the embedded timestamps.
I need to be able to build packages in a way that is completely reproducible, so that the same inputs gives me byte-for-byte the same package output.
For the files I'm packaging, I can set the
mtime
via the config file, or by changing the mtime on the file tree before running nfpm. However, there is no current mechanism for me to manage the timestamps generated within nFPM.Describe the solution you'd like
Make the package build process reproducible by using the standard
SOURCE_DATE_EPOCH
env var (if available) instead of usingtime.Now()
.More specifically, I think we can replace all of the
time.Now()
occurrences with one value calculated early on. Then, adjust that calculation to useSOURCE_DATE_EPOCH
instead, if available.This is the go example of calculating that:
https://reproducible-builds.org/docs/source-date-epoch/#go
We can probably also use this
build_date
for a defaultmtime
of package contents, but that is NOT what this issue is about. This issue is about controlling the current usages oftime.Now()
. These are the current instances that github search shows:https://github.com/search?q=repo%3Agoreleaser%2Fnfpm+time.now&type=code
Describe alternatives you've considered
A new cli flag, or any other non-standard option means any automation has to learn a new trick instead of reusing the standard env var. More detailed description on why the env var is better: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#A.22We.27ll_add_a_command-line_flag_instead.22
Search
Code of Conduct
Additional context
More background on why reproducible builds are important: https://reproducible-builds.org/
The spec for
SOURCE_DATE_EPOCH
: https://reproducible-builds.org/specs/source-date-epoch/Apparently,
dpkg
automatically setsSOURCE_DATE_EPOCH
when building packages based on the latest entry in thedebian/changelog
file. Many other tools have adopted that standard as well:https://reproducible-builds.org/docs/source-date-epoch/#reading-the-variable
The text was updated successfully, but these errors were encountered: