5 ms·

In the "The importance of deterministic builds" section they write: > Security. Modifying binaries instead of the upstream source code can make the changes inv

In the "The importance of deterministic builds" section they write: > Security. Modifying binaries instead of the upstream source code can make the changes invisible for the original authors. This can be fatal in safety-critical environments such as medical, aerospace and automotive. Promising identical results for given inputs allows third parties to come to a consensus on a correct result. I don't understand this argument, or rather what deterministic builds have to do with this. Isn't modifying the binary instead of the source just a very bad idea in a high stakes scenario?

jacoblambda 7y ago
Yes it is, however it is much more difficult to tell if said binary has been tampered with if you can't reliably build the exact same binary.
TACIXAT 7y ago
Someone could mess with the compiler, inserting am LLVM pass or similar into the build pipeline.
e12e 7y ago
Authors could publish official builds with a signature - but you can't build the same binary, so you can't be sure published source and binaries match. Say you checkout "libmagnificent" from github, browse the source and like what you see. You can build a binary and see it matches the upstream build. This gives you some (more) confidence in upstream builds. It also lets you know you're starting from a known good source, if you want to make modifications; the changes in the build come from the changes you made to the source - not through some side effect in the build process.
msbarnett 7y ago
Yeah, the author’s example is an odd and unlikely one. The real security concern is “you’ve audited the source code for some level of safety criticalness and validated it. What guarantee do you now have that the binary you’re told was built from that exact state of source code, actually was?” A concrete example being the UK’s audit of some Huawei firmware source code, which basically concluded “in addition to the issues we found, the builds are highly non-deterministic and we have no way of verifying whether a given firmware blob was actually built from this source or may have differed in any number of ways”

jacoblambda 7y ago

Yes it is, however it is much more difficult to tell if said binary has been tampered with if you can't reliably build the exact same binary.

TACIXAT 7y ago

Someone could mess with the compiler, inserting am LLVM pass or similar into the build pipeline.

e12e 7y ago

Authors could publish official builds with a signature - but you can't build the same binary, so you can't be sure published source and binaries match. Say you checkout "libmagnificent" from github, browse the source and like what you see. You can build a binary and see it matches the upstream build. This gives you some (more) confidence in upstream builds. It also lets you know you're starting from a known good source, if you want to make modifications; the changes in the build come from the changes you made to the source - not through some side effect in the build process.

msbarnett 7y ago

Yeah, the author’s example is an odd and unlikely one. The real security concern is “you’ve audited the source code for some level of safety criticalness and validated it. What guarantee do you now have that the binary you’re told was built from that exact state of source code, actually was?” A concrete example being the UK’s audit of some Huawei firmware source code, which basically concluded “in addition to the issues we found, the builds are highly non-deterministic and we have no way of verifying whether a given firmware blob was actually built from this source or may have differed in any number of ways”