PE binaries contain a timestamp.

Known affected packages

Detection

Example debbindiff output

Possible work-arounds

None yet.

Tor Browser and Bitcoin developers probably have insights on how to solve this.

Resources: 1

strip-nondeterminism should be taught how to handle them: patch for very, very first timestamp (in the header); this is not enough.

Chromium is using zap_timestamps. This is worth exploring.

Solution

building with mono

discusson on mono upstream bugtracker about enabling externally-set timestamps during the build process of PE modules. (not ready in debian yet)

building with mingw-w64

To completely drop PE timestamps, supply -Xlinker --no-insert-timestamp as arguments to i686-w64-mingw32-gcc. This works for executables, but DLLs builts like this cause problems with bound executables: updating a DLL without changing its timestamp causes bound executables to crash. See https://sourceware.org/bugzilla/show_bug.cgi?id=16887 for details.

Since binutils-mingw-w64 version 6.2 (binary packages with versions ending in +6.2, 2.25-8+6.2 in the archive), the --insert-timestamp option accepts an optional timestamp expressed in milliseconds since the epoch; so something like -Xlinker --insert-timestamp=$(date -d "$(dpkg-parsechangelog -S Date)" +%s) will fix the timestamp to the date of the last changelog entry. This allows packages to build reproducibly but also ensures that new versions of DLLs get new timestamps. The option doesn't take any arguments on older versions of binutils or on current upstream binutils, so packages using this must build-depend on binutils-mingw-w64-{i686,x86-64} (>= 2.25-8+6.2). If you decide to use this please inform skitt@d.o so I can help you with any changes to the option.