patternMinor
What exactly are "Truly reproducible builds"?
Viewed 0 times
whatbuildsarereproducibletrulyexactly
Problem
What exactly are they? Why are they important, in the domain of Continuous Delivery?
Context: I have seen in one of (I guess reddit)'s comments that Truly Reproducible builds are still an under-research technology, and is very difficult to create.
So, I wanted to know why are they so difficult to create?
Context: I have seen in one of (I guess reddit)'s comments that Truly Reproducible builds are still an under-research technology, and is very difficult to create.
So, I wanted to know why are they so difficult to create?
Solution
What exactly are they?
Here is a quote from reproducible-builds.org:
Reproducible builds are a set of software development practices that create a verifiable path from human readable source code to the binary code used by computers.
Why are they important?
IMO the easiest way to explain their importance is to consider them as a variation of a backup procedure.
As an example:
-
Assume a business which uses (depends) on some software package licensed from some software vendor. Whereas the business only gets the executables, not the sources, etc that were used to create those executables.
-
Everything goes well, but at some point something goes wrong with the software vendor, e.g. they go out of business (eg bankrupcy).
-
This may expose a risk to the business (in the long run). I.e. if there is no procedure/agreement in place for the business to get (legal) access to all required sources, documentation, build procedures, etc related to anything from the software vendor used (back in the days) when the executables (used by the business) were created (and shipped to the business).
-
That's were "Software Escrow" comes to the rescue: if there is such agreement in place, one would think that via a 3rd party, it would still be possible for the business to get access to "whatever was used" to be able to reproduce the executables, so that from there on, the business might have a chance to continue to use that software, and where apropriate start maintaining it themselves (for only running their own business).
-
However, the "whatever was used" in the previous bullet is the toughest part to make this work. It requires that the 3rd party performs appropriate validations upfront. And trust me, it takes a while before you can recreate an executable for which you can prove that, apart from (eg) the link date, it is a perfect match with what the software vendor delivers to the software agent.
And why are they so difficult to create?
If the above sample is still not clear enough, imagine you're my software escrow agent, tell me what you need as input to recreate a copy of the software licensed by my customer. Get it? You didn't forget to check about which version of my compiler, maybe my OS, compile/link options, versions of reusable components (includes), libraries, etc?
Here is a quote from reproducible-builds.org:
Reproducible builds are a set of software development practices that create a verifiable path from human readable source code to the binary code used by computers.
Why are they important?
IMO the easiest way to explain their importance is to consider them as a variation of a backup procedure.
As an example:
-
Assume a business which uses (depends) on some software package licensed from some software vendor. Whereas the business only gets the executables, not the sources, etc that were used to create those executables.
-
Everything goes well, but at some point something goes wrong with the software vendor, e.g. they go out of business (eg bankrupcy).
-
This may expose a risk to the business (in the long run). I.e. if there is no procedure/agreement in place for the business to get (legal) access to all required sources, documentation, build procedures, etc related to anything from the software vendor used (back in the days) when the executables (used by the business) were created (and shipped to the business).
-
That's were "Software Escrow" comes to the rescue: if there is such agreement in place, one would think that via a 3rd party, it would still be possible for the business to get access to "whatever was used" to be able to reproduce the executables, so that from there on, the business might have a chance to continue to use that software, and where apropriate start maintaining it themselves (for only running their own business).
-
However, the "whatever was used" in the previous bullet is the toughest part to make this work. It requires that the 3rd party performs appropriate validations upfront. And trust me, it takes a while before you can recreate an executable for which you can prove that, apart from (eg) the link date, it is a perfect match with what the software vendor delivers to the software agent.
And why are they so difficult to create?
If the above sample is still not clear enough, imagine you're my software escrow agent, tell me what you need as input to recreate a copy of the software licensed by my customer. Get it? You didn't forget to check about which version of my compiler, maybe my OS, compile/link options, versions of reusable components (includes), libraries, etc?
Context
StackExchange DevOps Q#482, answer score: 8
Revisions (0)
No revisions yet.