4 ms·
And that's why modern compilers won't have that. It was exactly so the same source, even compiled a second later, it will generate different binary file. I hat
by unnouinceput 6y ago
And that's why modern compilers won't have that. It was exactly so the same source, even compiled a second later, it will generate different binary file.
I hate it. It was so easy in DOS era - same source, same binary file, easy peasy.
- pabs3 6y agoThe reproducible builds folks are working on fixing that: https://reproducible-builds.org/ https://reproducible-builds.org/
- segfaultbuserr 6y agoThe major variables in modern compilers are just automatic timestamps, exploit mitigation random seeds, and toolchain versions, it is possible to make them immutable. The problem can be fixed, and there are already major projects to address it. Do you know that 90% of the Debian packages are already reproducible [0]? [0] https://isdebianreproducibleyet.com https://isdebianreproducibleyet.com
- beagle3 6y agoThat’s true. But that may also be a plausible deniability thing - you create a place to hide binary modifications by making sure no two builds are exactly the same. It could be chalked to some lack of care; however, up until 2000 or so, non reproducible builds were considered a bug in at least two places I worked in. The fact that it has become so hard to make builds reproducible could be Increased “entropy” (because no one cares To fix it) - but it could also be orchestrated by someone with a vested interest. E.g. - suppose you are a three letter agency, and want to implement a “reflections on trusting trust” attack. Non reproducible builds become a pre-requisite.
- segfaultbuserr 6y agoNo disagreement. It's why the problem needs to be fixed, although it's not a silver bullet (the compiler bootstrapping is still vulnerable).
- int_19h 6y agoMost modern compilers have switches to disable this behavior.