Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of __DATE__ breaks build reproducibility #817

Closed
jmallach opened this issue Apr 16, 2016 · 2 comments
Closed

Use of __DATE__ breaks build reproducibility #817

jmallach opened this issue Apr 16, 2016 · 2 comments

Comments

@jmallach
Copy link
Contributor

Consider the following patch:

Author: Jordi Mallach <jordi@debian.org>
Description: Remove date of build to ensure binary reproducibility.
Forwarded: no

Index: mame-0.171/src/version.cpp
===================================================================
--- mame-0.171.orig/src/version.cpp
+++ mame-0.171/src/version.cpp
@@ -13,4 +13,4 @@
 extern const char bare_build_version[];
 extern const char build_version[];
 const char bare_build_version[] = BARE_BUILD_VERSION;
-const char build_version[] = BARE_BUILD_VERSION " (" __DATE__")";
+const char build_version[] = BARE_BUILD_VERSION;

With this I avoid using DATE which just adds the compilation date to the version string. As that probably is not meaningful at all (we probably care a lot more about the release date instead of the build date), I removed it from Debian as our compiler defaults doesn't like it.

However, I don't want to change the version string as some frontends rely on a specific string format.

I am unsure how to rework things so it uses a RELEASE_DATE macro or something, that resolves to the date of the actual MAME release, or a git snapshot in the case of a git build. In the latter case, I would add an extra string "from git " or something).

In short, using DATE means every build will not be binary exact unless you tamper with the build system clock to make it match. Being able to create exact binaries is a goal to provide extra security to detect malicious 3rd party tampering of systems. See https://reproducible-builds.org/ for way too many details.

What do you think?

@mmicko
Copy link
Member

mmicko commented Apr 16, 2016

Agree that at least at release time it have to be unique, also date does
not make much sense.

Making build process to set variable for building at current git version
unless it match release tag it will be enough I think. That way we will
have exact git guid on non-release builds and that part empty at release
time

On Sat, Apr 16, 2016 at 9:16 AM, Jordi Mallach notifications@github.com
wrote:

Consider the following patch:

Author: Jordi Mallach jordi@debian.org
Description: Remove date of build to ensure binary reproducibility.
Forwarded: no

Index: mame-0.171/src/version.cpp

--- mame-0.171.orig/src/version.cpp
+++ mame-0.171/src/version.cpp
@@ -13,4 +13,4 @@
extern const char bare_build_version[];
extern const char build_version[];
const char bare_build_version[] = BARE_BUILD_VERSION;
-const char build_version[] = BARE_BUILD_VERSION " (" DATE")";
+const char build_version[] = BARE_BUILD_VERSION;

With this I avoid using DATE which just adds the compilation date to
the version string. As that probably is not meaningful at all (we probably
care a lot more about the release date instead of the build date), I
removed it from Debian as our compiler defaults doesn't like it.

However, I don't want to change the version string as some frontends rely
on a specific string format.

I am unsure how to rework things so it uses a RELEASE_DATE macro or
something, that resolves to the date of the actual MAME release, or a git
snapshot in the case of a git build. In the latter case, I would add an
extra string "from git " or something).

In short, using DATE means every build will not be binary exact unless
you tamper with the build system clock to make it match. Being able to
create exact binaries is a goal to provide extra security to detect
malicious 3rd party tampering of systems. See
https://reproducible-builds.org/ for way too many details.

What do you think?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#817

@mmicko
Copy link
Member

mmicko commented Apr 28, 2016

This is implemented and effective in 0.173

@mmicko mmicko closed this as completed Apr 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants