>First, we'd love it if you would try our early container prototype on your build. Contact us and we'll add you to our closed alpha test. If the code is availa

>First, we'd love it if you would try our early container prototype on your build. Contact us and we'll add you to our closed alpha test. If the code is available; sure. If it's not then sadly this isn't interesting. >Also, we can send you the full paper (preprint) on the Debian case study, with the gory details. This would be more interesting as I'm doing a master thesis regarding reproducible builds and rebuilders for debian at this moment, along with contributing to the effort in general. Feel free to send a copy to morten@linderud.pw >The compiler can inject malware when it recognizes that its compiling itself, but we run arbitrary build systems, compiler tool chains, JITs. The compiler can inject anny backdoor into any code as long as its invoked. We are not strictly limited to it compiling itself. I'm unsure how appealing to the diversity of the things you compile is an argument. A lot of things utilize `ld`, `gcc` or `tar` somewhere in their build chain regardless of what they build. It's not going to be harder to backdoor something if you have enough diversity. This is a neat example of the possibilities you have with the rust compiler as an example: https://manishearth.github.io/blog/2016/12/02/reflections-on-rusting-trust/ https://manishearth.github.io/blog/2016/12/02/reflections-on... >The DRB website lists a Ph.D. dissertation on improving this situation, but I haven't read it, and I don't think it's been implemented in DRB Davids PhD hasn't really been implemented to any large extent in the real-world, beside smaller toy examples, as it would need a second trusted compiler to verify. This is hard work and I don't see anyone actually want to implement a second compiler to C++18 (as an example) to help verify the gcc output they are getting.