11 ms·

What's the importance of reproducible builds? Edit: found this nice overview by clicking a few links from the original post https://reproducible-builds.org/ ht

What's the importance of reproducible builds? Edit: found this nice overview by clicking a few links from the original post https://reproducible-builds.org/ https://reproducible-builds.org/

johnmaguire2013 8y ago
It allows you to verify that the source code was unaltered when the original build was produced. (By building it a second time with known good code.)
- keanebean86 8y ago
  Does anyone diff public releases with builds done using a known good environment? It would be a lot of work but could expose malicious providers. Then again it might be hard to create an actual good environment considering all the software /firmware/hardware layers modern systems have.
  - orblivion 8y ago
    See here for an example: https://gitian.org/ https://gitian.org/. As I understand it's used to build a (the?) Bitcoin client.
  - kpcyrd 8y ago
    Yes, this is known as a rebuilder. There is still work to be done, but NYU was one of the organizations working on developing and running a rebuilder. The idea is that you pull buildinfo files from https://buildinfo.debian.net/ https://buildinfo.debian.net/, then try to verify them and if you got the same artifact you sign that you successfully verified this binary package. A user could then configure "I trust rebuilder X, Y, Z and I require that at least N have successfully verified the package" before installing it.
bognition 8y ago
Its extremely valuable for debugging. When you've got a bug that is in a specific build you can collect the set of dependencies that produced that build and BAM you've got an env that should replicate the bug.
- nickpsecurity 8y ago
  This is the best argument Ive heard for it. It's also an argument for my priorities of safer languages, development rigour, and use of vetification and test tooling. Each of these reduce amount of debugging one does later on top of improving reliability and security.
convolvatron 8y ago
one thing that I think got lost culturally in the move to linux was the emphasis on open source. yes, not open source in some abstract warm fuzzy way, but actual useful open source. if I cant run the build process, and I dont really know which patch sets have been applied on my system, and which version of the source was used, and I dont really have a handle on the dependencies. doesn't make it substantially more difficult to debug and work with the resulting system? its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on.
- jrockway 8y ago
  > its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on It's not that odd. Reproducible builds are very hard. "gcc foo.c -o foo" is very easy.
  - giancarlostoro 8y ago
    Also as a sibling comment mentioned it's not priority number one. People were happy they didn't have to compile the whole damn thing anymore.
- pjc50 8y ago
  Move to Linux from where? Windows? SunOS? > its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on It was perfectly logical when I was installing slackware from floppies, and it remains more useful in most use cases - smaller downloads that installed faster. Debian's great innovation was dependency management of binary packages, after all.
  - convolvatron 8y ago
    oh yes, sorry, yes I'm that old. before linux, except for maybe gcc, open source was largely distributed as source. and I agree that installing linux as a binary makes sense. but people didn't think it was important to maintain the reference back to the actual source used. I think to some extent (RedHat specifically), the patch sets used and the hidden build process was used to make it less trivial to reproduce.
groestl 8y ago
One thing that gets me excited about reproducible build systems in general, which has less to do with trust and verifiability, is cacheability/content addressable storage of build artifacts.
nickpsecurity 8y ago
Not much. Mostly a fad. Repo security plus secure transport handles most of the risk there. Whereas, most black hats will use bad configurations, social engineering, or app/OS vulnerabilities. There's enough of those that vulnerability brokers aren't paying high for hitting that OS. So, best use of time would be one of three activities: 1. Gradually rewriting apps or kernels in safe languages. Can even make stuff reproducible as a side effect of rewrites. 2. Improving tools like SAFEcode snd Softbound+CETS that make C code safe. Esp usability and packaging. If not that, then more mitigations in OS like OpenBSD does. Can even port theirs. 3. Running static analyzers, fuzzers, etc on all that code out there. Then, fixing the vulnerabilities. Id say prioritize highly-priveleged and newest code. That would actually improve the security of Debian against the kind of attacks that hit it the most. There's some people doing this. Not enough by far.
- sanxiyn 8y ago
  While I mostly agree with your assessment on "best use of time", labor is not fungible and cannot be redirected like that.
  - nickpsecurity 8y ago
    Labor can be pulled or pushed in certain directions. They're bringing in labor on reproducible builds. I'm saying they bring it in on QA. Those currently directing it try to move it in a different direction.

What's the importance of reproducible builds? Edit: found this nice overview by clicking a few links from the original post https://reproducible-builds.org/ https://reproducible-builds.org/

johnmaguire2013 8y ago

It allows you to verify that the source code was unaltered when the original build was produced. (By building it a second time with known good code.)

keanebean86 8y ago
Does anyone diff public releases with builds done using a known good environment? It would be a lot of work but could expose malicious providers. Then again it might be hard to create an actual good environment considering all the software /firmware/hardware layers modern systems have.
- orblivion 8y ago
  See here for an example: https://gitian.org/ https://gitian.org/. As I understand it's used to build a (the?) Bitcoin client.
- kpcyrd 8y ago
  Yes, this is known as a rebuilder. There is still work to be done, but NYU was one of the organizations working on developing and running a rebuilder. The idea is that you pull buildinfo files from https://buildinfo.debian.net/ https://buildinfo.debian.net/, then try to verify them and if you got the same artifact you sign that you successfully verified this binary package. A user could then configure "I trust rebuilder X, Y, Z and I require that at least N have successfully verified the package" before installing it.

bognition 8y ago

Its extremely valuable for debugging. When you've got a bug that is in a specific build you can collect the set of dependencies that produced that build and BAM you've got an env that should replicate the bug.

nickpsecurity 8y ago
This is the best argument Ive heard for it. It's also an argument for my priorities of safer languages, development rigour, and use of vetification and test tooling. Each of these reduce amount of debugging one does later on top of improving reliability and security.

convolvatron 8y ago

one thing that I think got lost culturally in the move to linux was the emphasis on open source. yes, not open source in some abstract warm fuzzy way, but actual useful open source. if I cant run the build process, and I dont really know which patch sets have been applied on my system, and which version of the source was used, and I dont really have a handle on the dependencies. doesn't make it substantially more difficult to debug and work with the resulting system? its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on.

jrockway 8y ago
> its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on It's not that odd. Reproducible builds are very hard. "gcc foo.c -o foo" is very easy.
- giancarlostoro 8y ago
  Also as a sibling comment mentioned it's not priority number one. People were happy they didn't have to compile the whole damn thing anymore.
pjc50 8y ago
Move to Linux from where? Windows? SunOS? > its really quite odd that the dominant open source platform settled on opaque and unreproducible binaries as the distribution mechanism early on It was perfectly logical when I was installing slackware from floppies, and it remains more useful in most use cases - smaller downloads that installed faster. Debian's great innovation was dependency management of binary packages, after all.
- convolvatron 8y ago
  oh yes, sorry, yes I'm that old. before linux, except for maybe gcc, open source was largely distributed as source. and I agree that installing linux as a binary makes sense. but people didn't think it was important to maintain the reference back to the actual source used. I think to some extent (RedHat specifically), the patch sets used and the hidden build process was used to make it less trivial to reproduce.

groestl 8y ago

One thing that gets me excited about reproducible build systems in general, which has less to do with trust and verifiability, is cacheability/content addressable storage of build artifacts.

nickpsecurity 8y ago

Not much. Mostly a fad. Repo security plus secure transport handles most of the risk there. Whereas, most black hats will use bad configurations, social engineering, or app/OS vulnerabilities. There's enough of those that vulnerability brokers aren't paying high for hitting that OS. So, best use of time would be one of three activities: 1. Gradually rewriting apps or kernels in safe languages. Can even make stuff reproducible as a side effect of rewrites. 2. Improving tools like SAFEcode snd Softbound+CETS that make C code safe. Esp usability and packaging. If not that, then more mitigations in OS like OpenBSD does. Can even port theirs. 3. Running static analyzers, fuzzers, etc on all that code out there. Then, fixing the vulnerabilities. Id say prioritize highly-priveleged and newest code. That would actually improve the security of Debian against the kind of attacks that hit it the most. There's some people doing this. Not enough by far.

sanxiyn 8y ago
While I mostly agree with your assessment on "best use of time", labor is not fungible and cannot be redirected like that.
- nickpsecurity 8y ago
  Labor can be pulled or pushed in certain directions. They're bringing in labor on reproducible builds. I'm saying they bring it in on QA. Those currently directing it try to move it in a different direction.