3 ms·

I think adding telemetry to a compiler goes in the opposite direction of the current "minimal privileges, sandbox all the things" trend. For instance, it would

by cesarb 3y ago

I think adding telemetry to a compiler goes in the opposite direction of the current "minimal privileges, sandbox all the things" trend. For instance, it would make sense to create a set of selinux rules (or something like it) to make sure that a compiler cannot do anything other than reading its input files (and system headers/libraries/etc) and writing to its output directory, even if for instance a buffer overflow triggered by a malicious source code file led to running shell code within the compiler. Having to allow access to the network for the telemetry would require weakening these rules. It reminds me of the classic "confused deputy" article (https://css.csail.mit.edu/6.858/2015/readings/confused-deputy.html https://css.csail.mit.edu/6.858/2015/readings/confused-deput...), which coincidentally also involved a compiler tracking statistics about its usage.

arp242 3y ago
That would actually already be difficult with the current go tool, since it's more than "just" a compiler but also fetches dependencies. If all dependencies are already in place it won't hit the network, so there are options, but you'd have to find another way to retrieve those. The telemetry is opt-in,and failing to send them won't fail the compile (it won't even run on every compile). It's not really preventing you from applying your SELinux policy if you want, even if it would have been opt-out.
duped 3y ago
> to make sure that a compiler cannot do anything other than reading its input files (and system headers/libraries/etc) Define "input files." Tools have to do a combination of reading, parsing, and sometimes even version unification/downloads just to get the complete set of inputs to feed to the compiler. Of course you can define the compiler as the tool that parses text and writes machine code, but then you're just shoveling dirty water around.

by cesarb 3y ago

arp242 3y ago

That would actually already be difficult with the current go tool, since it's more than "just" a compiler but also fetches dependencies. If all dependencies are already in place it won't hit the network, so there are options, but you'd have to find another way to retrieve those. The telemetry is opt-in,and failing to send them won't fail the compile (it won't even run on every compile). It's not really preventing you from applying your SELinux policy if you want, even if it would have been opt-out.

duped 3y ago

> to make sure that a compiler cannot do anything other than reading its input files (and system headers/libraries/etc) Define "input files." Tools have to do a combination of reading, parsing, and sometimes even version unification/downloads just to get the complete set of inputs to feed to the compiler. Of course you can define the compiler as the tool that parses text and writes machine code, but then you're just shoveling dirty water around.