4 ms·

For this problem, where the resulting code does not correspond to the published source code, reproducible builds is an adequate solution. https://reproducible-

For this problem, where the resulting code does not correspond to the published source code, reproducible builds is an adequate solution. https://reproducible-builds.org/docs/buy-in/ https://reproducible-builds.org/docs/buy-in/ When it comes to verifying this, we need to have independent rebuilders that build these packages reproducibly, and can attest these rebuilds in a secure manner. I have been working with NYU Secure System Labs to try provide this to debian packages and we currently have a PoC for such a system. https://reproducible-builds.org/docs/sharing-certifications/ https://reproducible-builds.org/docs/sharing-certifications/ https://ssl.engineering.nyu.edu/blog/2019-01-18-in-toto-paris https://ssl.engineering.nyu.edu/blog/2019-01-18-in-toto-pari...

ChrisCinelli 8y ago
Not trivial to do when the build changes each time. For example adding the build number or the date of when it is built. But I think this goes in the right direction.
- ChrisCinelli 8y ago
  Unfortunately a few well know projects do not let you compile from source easily. Brew for example is going in that direction.
- Foxboron 8y ago
  Already adresse in the documentation in the form of "SOURCE_DATE_EPOCH". Adding these things to projects in general is terrible.
  - ChrisCinelli 8y ago
    Sure there are ways to do it, but every piece of software needs to be aligned. What I was trying to say is that even if you have the tools you probably cannot "just use the tools". You will likely have to create patches for those piece of softwares that create a different artifact every time are built. There are a few other challenges but in my humble opinion, it is worthwhile to strive to write your own software with "reproducible builts" in mind so everybody can verify if something was altered.
    - Foxboron 8y ago
      We are well aware of the challenges. Read a bit into the documentation and the efforts that has gone into achieving reproducible builds on different distributions. This is hard on distributions as we are suppose to support all the ecosystems. But for rubygems, pypi, go, rust, npm and so on this is a easier problem to solve if they want to. But even with all these challenges, Debian is at 94% reproducible packages, and Arch is edging closer to 80%. Introducing non-determinism into your build process is something that should be removed, and all ecosystems should be aligned in this effort. Weekly blog posts are written about the current efforts. https://reproducible-builds.org/blog/ https://reproducible-builds.org/blog/
    - ChrisCinelli 8y ago
      Again, we are on the same page. 80% is what I was expecting. 94% is very good!

ChrisCinelli 8y ago

Not trivial to do when the build changes each time. For example adding the build number or the date of when it is built. But I think this goes in the right direction.

ChrisCinelli 8y ago
Unfortunately a few well know projects do not let you compile from source easily. Brew for example is going in that direction.
Foxboron 8y ago
Already adresse in the documentation in the form of "SOURCE_DATE_EPOCH". Adding these things to projects in general is terrible.
- ChrisCinelli 8y ago
  Sure there are ways to do it, but every piece of software needs to be aligned. What I was trying to say is that even if you have the tools you probably cannot "just use the tools". You will likely have to create patches for those piece of softwares that create a different artifact every time are built. There are a few other challenges but in my humble opinion, it is worthwhile to strive to write your own software with "reproducible builts" in mind so everybody can verify if something was altered.
  - Foxboron 8y ago
    We are well aware of the challenges. Read a bit into the documentation and the efforts that has gone into achieving reproducible builds on different distributions. This is hard on distributions as we are suppose to support all the ecosystems. But for rubygems, pypi, go, rust, npm and so on this is a easier problem to solve if they want to. But even with all these challenges, Debian is at 94% reproducible packages, and Arch is edging closer to 80%. Introducing non-determinism into your build process is something that should be removed, and all ecosystems should be aligned in this effort. Weekly blog posts are written about the current efforts. https://reproducible-builds.org/blog/ https://reproducible-builds.org/blog/
  - ChrisCinelli 8y ago
    Again, we are on the same page. 80% is what I was expecting. 94% is very good!