7 ms·

Doesn't Bazel hash the compiler and env variables to prevent this? The only way to poison the cache then is to break things at an OS level, which is highly unl

by adgasf 7y ago

Doesn't Bazel hash the compiler and env variables to prevent this? The only way to poison the cache then is to break things at an OS level, which is highly unlikely.

theamk 7y ago
Oh, it is pretty simple to poison the cache. Bazel does not really hash any of the system stuff -- like system headers, and system-provided .a and .so files (unless they are explicitly declared in WORKSPACE, but this is optional, and I have never seen this done for libc stuff fot example). So all you need to do is to find one person who likes to mess with their system (for example, by installing latest versions of the libraries from random PPA's), and you'll end up with poisoned cache for everyone.
- vlovich123 7y ago
  On any large team your compiler should be checked into revision control or have a way to fetch a specific artifact & have that pointer checked in. That way you're guaranteeing everyone is using the right thing.
  - theamk 7y ago
    Are you talking in general, or bazel specifically? Because in general yes, I agree, it would be nice. Probably not in source control though -- putting in compilers + libraries will make checkouts very slow, git is not really designed for tens of gigabytes of stuff. For bazel specifically, this is not really well supported. The default rules and all examples just trust system-installed compilers. There is ongoing work on building in docker (with all the corresponding security issues), and there are rumors that Google internal version has some sort of magic, but this is not a "mainstream" configuration.
    - kornholi 7y ago
      That's not exactly true, for example see https://github.com/grailbio/bazel-toolchain https://github.com/grailbio/bazel-toolchain
      - theamk 7y ago
        I am glad there is work going towards bazel-ifying the toolchain! And maybe now that 1.0 is out, we will see more work like this. However, I think my point still stands -- this work looks pretty experimental. And most tutorials, including bazel's own [0], recommend using default configuration, which uses system compiler. And most of the examples I have seen also rely on system compiler. [0] https://docs.bazel.build/versions/master/tutorial/cpp.html https://docs.bazel.build/versions/master/tutorial/cpp.html
        rfoo 7y ago
        For the record, in the beginning Bazel does not support using auto-configured system compiler at all. The only thing it supports is using a controlled build environment and hardcode all paths (including compiler paths), or using a checked-in toolchain. But at a later stage a dumb autoconf-y "detect system toolchain and try to use it" thing was added and it became default. This is because configuring a checked-in toolchain in Bazel needs tremendous effort and very specific knowledge about something 99.9% of developers does not know and DOES NOT WANT to know or spend their time on.

by adgasf 7y ago

Doesn't Bazel hash the compiler and env variables to prevent this? The only way to poison the cache then is to break things at an OS level, which is highly unlikely.

theamk 7y ago

Oh, it is pretty simple to poison the cache. Bazel does not really hash any of the system stuff -- like system headers, and system-provided .a and .so files (unless they are explicitly declared in WORKSPACE, but this is optional, and I have never seen this done for libc stuff fot example). So all you need to do is to find one person who likes to mess with their system (for example, by installing latest versions of the libraries from random PPA's), and you'll end up with poisoned cache for everyone.

vlovich123 7y ago
On any large team your compiler should be checked into revision control or have a way to fetch a specific artifact & have that pointer checked in. That way you're guaranteeing everyone is using the right thing.
- theamk 7y ago
  Are you talking in general, or bazel specifically? Because in general yes, I agree, it would be nice. Probably not in source control though -- putting in compilers + libraries will make checkouts very slow, git is not really designed for tens of gigabytes of stuff. For bazel specifically, this is not really well supported. The default rules and all examples just trust system-installed compilers. There is ongoing work on building in docker (with all the corresponding security issues), and there are rumors that Google internal version has some sort of magic, but this is not a "mainstream" configuration.
  - kornholi 7y ago
    That's not exactly true, for example see https://github.com/grailbio/bazel-toolchain https://github.com/grailbio/bazel-toolchain
    - theamk 7y ago
      I am glad there is work going towards bazel-ifying the toolchain! And maybe now that 1.0 is out, we will see more work like this. However, I think my point still stands -- this work looks pretty experimental. And most tutorials, including bazel's own [0], recommend using default configuration, which uses system compiler. And most of the examples I have seen also rely on system compiler. [0] https://docs.bazel.build/versions/master/tutorial/cpp.html https://docs.bazel.build/versions/master/tutorial/cpp.html
      - rfoo 7y ago
        For the record, in the beginning Bazel does not support using auto-configured system compiler at all. The only thing it supports is using a controlled build environment and hardcode all paths (including compiler paths), or using a checked-in toolchain. But at a later stage a dumb autoconf-y "detect system toolchain and try to use it" thing was added and it became default. This is because configuring a checked-in toolchain in Bazel needs tremendous effort and very specific knowledge about something 99.9% of developers does not know and DOES NOT WANT to know or spend their time on.