4 ms·

> Is it a bad thing? Yes. It makes verifiability much harder. E.g. Debian put a lot of work into making a more trustworthy build chain by introducing reproduc

by hannob 7y ago

> Is it a bad thing? Yes. It makes verifiability much harder. E.g. Debian put a lot of work into making a more trustworthy build chain by introducing reproducible builds. There's no Bazel on Debian. And not on many other distros. Because getting Bazel to be built itself is a complexity nightmare. "Here, download this big blob where you have no idea how it's been built" doesn't exactly help.

zerkten 7y ago
Could the Bazel folks better define the composition of their blob? That way they can distribute their blob, but someone could substitute for another instance of the JVM. I'm assuming ownership of this lies with Bazel and this is more of a political/motivation problem than a technical one. Or, is that incorrect?
- hannob 7y ago
  Sure, this is not impossible. But there's a simple fact: The more complex your build chain is the more difficult this is. And Java adds a whole bunch of complexity. Read into the bug report to get an idea what a nightmarish task this is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654
- lima 7y ago
  The blob is just the JDK + Bazel + a wrapper binary. Just use their regular build artifacts instead if you want to bring your own JDK.
danpalmer 7y ago
I don't think bundling in components inherently changes the reproducible builds equation. In fact I think that bundling in a JVM that they know works in a particular way will likely improve the reproducibility of Bazel _setups_ and therefore builds that come out of Bazel, which is their aim.
- DuskStar 7y ago
  "every time the NSA's compiler binary builds my code I get the same output" isn't really all that comforting. If you can't build the compiler (and/or build tool) how can you be sure that there isn't anything malicious in it? Trusting trust all over again
new_realist 7y ago
What’s so hard about: env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh. To build the bazel binary in a reproducible way, also set SOURCE_DATE_EPOCH.

by hannob 7y ago

zerkten 7y ago

Could the Bazel folks better define the composition of their blob? That way they can distribute their blob, but someone could substitute for another instance of the JVM. I'm assuming ownership of this lies with Bazel and this is more of a political/motivation problem than a technical one. Or, is that incorrect?

hannob 7y ago
Sure, this is not impossible. But there's a simple fact: The more complex your build chain is the more difficult this is. And Java adds a whole bunch of complexity. Read into the bug report to get an idea what a nightmarish task this is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654
lima 7y ago
The blob is just the JDK + Bazel + a wrapper binary. Just use their regular build artifacts instead if you want to bring your own JDK.

danpalmer 7y ago

I don't think bundling in components inherently changes the reproducible builds equation. In fact I think that bundling in a JVM that they know works in a particular way will likely improve the reproducibility of Bazel _setups_ and therefore builds that come out of Bazel, which is their aim.

DuskStar 7y ago
"every time the NSA's compiler binary builds my code I get the same output" isn't really all that comforting. If you can't build the compiler (and/or build tool) how can you be sure that there isn't anything malicious in it? Trusting trust all over again

new_realist 7y ago

What’s so hard about: env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh. To build the bazel binary in a reproducible way, also set SOURCE_DATE_EPOCH.