
A tool to make Windows builds reproducible - BuuQu9hu
https://github.com/jasonwhite/ducible
======
metaphor
Are modern compilers truly _that_ deterministic when processing arbitrarily
complex code, _shoot-yourself-in-the-foot_ example aside?

In the reconfigurable world, place and route engines run metaheuristics[1][2]
to find good-enough solutions in an intractable search space. I'm imagining if
there's a compiler stage which implements even a single optimization
heuristic, any prospect of hash-wise reproducibility goes out the window?

[1]
[https://en.wikipedia.org/wiki/Simulated_annealing](https://en.wikipedia.org/wiki/Simulated_annealing)

[2]
[https://en.wikipedia.org/wiki/Genetic_algorithm](https://en.wikipedia.org/wiki/Genetic_algorithm)

~~~
johntb86
If your random numbers are generated with a fixed seed and the algorithm runs
for a deterministic number of steps (e.g. not using a wall-clock timeout) then
the output should be deterministic.

One potential for nondeterminism is if the compiler or linker is
multithreaded, and multiple threads could update a shared data structure in no
fixed order.

~~~
metaphor
OP actually pointed to an interesting reference[1] which briefly touches on
the impact of pseudo-random number generation, amongst other things.

Diving a little bit deeper down the same rabbit hole, David A. Wheeler[2] (as
he emphatically insists on being cited) also made note of threads with non-
deterministic scheduling. Lots of notes on hardware-centric implications as
well.

Definitely turns my perspective around on what it means to _trust_ software. I
suppose the effort is a proper graduation from masturbating[3] to safe sex, so
to speak.

[1] [https://reproducible-builds.org/docs/](https://reproducible-
builds.org/docs/)

[2] [http://www.dwheeler.com/trusting-
trust/](http://www.dwheeler.com/trusting-trust/)

[3]
[https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...](https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=1664)

------
ddfs
Windows compilers aren't deterministic in some areas.

Roslyn already has a switch to do this, /deterministic.

There is a spec for this though, [https://www.microsoft.com/en-
us/download/confirmation.aspx?i...](https://www.microsoft.com/en-
us/download/confirmation.aspx?id=19509)

> A stamp that is used for different purposes in several places in a PE or
> COFF file. In most cases, the format of each stamp is the same as that used
> by the time functions in the C run-time library. For exceptions, see the
> descripton of IMAGE_DEBUG_TYPE_REPRO (section 6.1.2). If the stamp value is
> 0 or 0xFFFFFFFF, it does not represent a real or meaningful date/time stamp.

and

> The presence of an entry of type IMAGE_DEBUG_TYPE_REPRO indicates the PE
> file is built in a way to achieve determinism or reproducibility. If the
> input does not change, the output PE file is guaranteed to be bit-for-bit
> identical no matter when or where the PE is produced. Various date/time
> stamp fields in the PE file are filled with part or all the bits from a
> calculated hash value that uses PE file content as input, and therefore no
> longer represent the actual date and time when a PE file or related specific
> data within the PE is produced. The raw data of this debug entry may be
> empty, or may contain a calculated hash value preceded by a four-byte value
> that represents the hash value length.

~~~
fowl2
unless the key to reproducible builds is hidden somewhere inside "How to
Implement Compatible IDs in Printing Devices", that link may be wrong

~~~
ddfs
hit download and it pops up a window where you can select the correct doc.

It's PECoff.docx

------
civodul
It may be a helpful tool from an engineering viewpoint, but I think it misses
the big picture of _why_ reproducible builds matter:

[https://gnu.org/software/guix/news/reproducible-builds-a-
mea...](https://gnu.org/software/guix/news/reproducible-builds-a-means-to-an-
end.html)

------
milesf
I remember being new to Information Technology in 1998 when Windows 95 & 98
were the norm. I had more than one client who would take delivery of 10 - 12
new, identical workstations and it was very common to have half with one
problem and half without.

I'm not familiar with the concepts in this article. Would this explain the
sort of issues I had?

~~~
Retr0spectrum
Probably not, no.

------
Seylerius
On the one hand, my knee-jerk reaction to this involves a meaningful amount of
Windows-hate. In short: there is a tight limit to the amount of trust I can
give to any build on a platform that I can't build.

On the other hand, reproducible builds are /important/. The better we can
trust our tools and verify that they're exactly what we think they are, the
less we need to worry about the security of our tools, and the more we can get
on with /using them/.

In the end, despite enabling the continued use of a deeply proprietary and
anti-freedom platform, this is a good thing.

~~~
davexunit
Agreed. The GNU Guix project (of which I am one of the developers) sees
reproducibility as a means to an end: empowering users with verifiable,
trustable software that they can control. Thus, reproducible builds on a
proprietary system, while better than non-reproducible builds on a proprietary
system, don't accomplish very much for user freedom.

[https://www.gnu.org/software/guix/news/reproducible-
builds-a...](https://www.gnu.org/software/guix/news/reproducible-builds-a-
means-to-an-end.html)

------
ommunist
Very nice. But the title imposes that Windows builds are unique without a
tool.

------
jheriko
> Git is used to get the current commit hash.

that seems a bit of a problem for every product not using git (which is still
a lot, and whoever said git was the final solution anyway?)

