Don't embed the build date in the binary

[debfx]

For compatibility send a dummy date in the client/core handshake.

This makes it possible to create reproducible builds.

See also:
https://wiki.debian.org/ReproducibleBuilds/About

[Nevcairiel]

I like knowing when my core was built, I would vote against removing harmless features for some silly reasons.

[Zren]

Removing a format argument will shift the index of all other arguments.

[debfx]

It still works as arg() replaces the marker with the lowest number.
I'll clean up the markers anyway as it's a bit ugly like that.

[netzvieh]

Going with Nevcairiel here, if you want reproducible builds I'd suggest keeping this as patch in Debian or change the PR so you have an option for that in cmake.

[debfx]

I'm kinda disappointed that you disregard an effort to improve security without even bothering to give a single argument.

There is nothing Debian specific in this change. Debian just happens to be the first distro that makes a significant effort to get packages built reproducible.

I can work on turning this into an optional feature if you'd merge that.

[romibi]

I was thinking about this a bit...
Apart from the reason why a build should be reproducible (which I'm not 100% sure about) ...

Why not instead of removing the (build-)date completely, just replace it with a commit-date?
Most of the time it would be pretty close to each other and then those who want a date there are happy and the people who want reproducible builds are happy...

[AlD]

Sounds good to me.

romibi notifications@github.com schrieb am 26.10.2015:

I was thinking about this a bit...
Apart from the reason why a build should be reproducible (which I'm not
100% sure about) ...

Why not instead of removing the (build-)date completely, just replace
it with a commit-date?
Most of the time it would be pretty close to each other and then those
who want a date there are happy and the people who want reproducible
builds are happy...

---

Reply to this email directly or view it on GitHub:
#127 (comment)

[CounterPillow]

@romibi I'd be even fine if it just kept the commit hash in the code, since from that it's easy to find out what date the code is from. Build date is just a bad approximation of this anyway; it gives you an upper bound on how fresh the code is, but no actual info on what code the binary is actually built from. What you care about is a lower bound on how fresh the code is though, which the build date does not provide, and thus I fail to see its usefulness.

I'd be interested to hear whether anybody has arguments for keeping the build date, other than "it has always been there". For what it's worth, I also wouldn't describe reproducible builds as "silly reasons" - while Quassel is certainly not a prime target for maliciously altered packages like bitcoin is, it's still a nice to have property of the build system since it could allow for automated independent third party byte-for-byte reproduction of the builds.

[Nevcairiel]

@CounterPillow
The full git version is included already, the build date is just an extra piece of information.

[AlD]

Removing the build date entirely would also be fine with me. Just replacing it with a dummy date as proposed in debfx/quassel@d1107f3 is a bit too ugly.

[rsalinas]

I also think reproducible builds are something great, and that the price we pay by not including the BUILD timestamp is very little. The build time is actually not even related to the software version itself, so that it is not such a big loss. Anyway, we might well use the executable's creation timestamp to know the compilation time.

I also believe that hardcoding a false date is ugly.

[AlD]

Superseded by #159.