I see two issues with this. First, there may be other reasons for a reproducible build than simply "trust". This paper only focuses on that one use case.
For example, the ability to exactly reproduce a bug much later and then patch or study it. Say a customer reports a severe bug in a 5 year old build with a specific patch-set something like 3.1.8p16 with the blahmode 2.6 update installed or something. But you'd look foolish if you said we can't find the binaries, don't have the ability to rebuild them, and wouldn't know exactly what sources exactly were used "back then". What happens if it's important to forensically study, like in the https://en.wikipedia.org/wiki/Therac-25 software case? In any case it's just unprofessional.
Secondly, if you are concerned about trust, it's not necessarily the simplistic scenario presented which is perhaps unintentionally a strawman.
In my view Security/Trust => CM => reproducible (=> means implies, not is-equivalent). In other words reproducible builds is a prerequisite of configuration management. If you cannot produce the same binary twice with the "same" source, something is wrong. Maybe you haven't captured some subtle dependency from the build environment? Does it matter? If you don't know what caused that difference, I don't believe you adequately know what went into your product. CM is next one of a set prerequisites for trust. If you don't know what went into your product, then you can't convincingly argue that there's nothing bad in it - because again you don't know.
Now back to Trust => CM => reproducible. That does not mean reproducible => trust. But it does mean that lack of reproducible => lack of trust.
3 comments
[ 770 ms ] story [ 897 ms ] threadIf you can’t reproduce it you can’t easily patch it.
For example, the ability to exactly reproduce a bug much later and then patch or study it. Say a customer reports a severe bug in a 5 year old build with a specific patch-set something like 3.1.8p16 with the blahmode 2.6 update installed or something. But you'd look foolish if you said we can't find the binaries, don't have the ability to rebuild them, and wouldn't know exactly what sources exactly were used "back then". What happens if it's important to forensically study, like in the https://en.wikipedia.org/wiki/Therac-25 software case? In any case it's just unprofessional.
Secondly, if you are concerned about trust, it's not necessarily the simplistic scenario presented which is perhaps unintentionally a strawman.
In my view Security/Trust => CM => reproducible (=> means implies, not is-equivalent). In other words reproducible builds is a prerequisite of configuration management. If you cannot produce the same binary twice with the "same" source, something is wrong. Maybe you haven't captured some subtle dependency from the build environment? Does it matter? If you don't know what caused that difference, I don't believe you adequately know what went into your product. CM is next one of a set prerequisites for trust. If you don't know what went into your product, then you can't convincingly argue that there's nothing bad in it - because again you don't know.
Now back to Trust => CM => reproducible. That does not mean reproducible => trust. But it does mean that lack of reproducible => lack of trust.