4 ms·

Also: security. Does this feature imply that merely building someone else’s program executes their code on your machine?

mpalmer 2y ago
Syscalls aren't available to comptime code
- actionfromafar 2y ago
  Also see e.g. https://github.com/rust-lang/rust-analyzer/issues/14375 https://github.com/rust-lang/rust-analyzer/issues/14375
badsectoracula 2y ago
Considering that pretty much every non-toy project isn't built by directly calling the compiler but through build tools like make, cmake, autotools, etc or even scripts like `build.sh` that can call arbitrary commands and that even IDEs have functionality to let you call arbitrary commands before and after builds (and had since the 90s at least), i do not see this as a realistic concern worth of limiting a language's functionality.
- adonovan 2y ago
  Just because most projects’ builds have large attack surfaces doesn’t mean we should accept that. The build and IDE tooling for Go does not trust the code it consumes.
  - badsectoracula 2y ago
    That doesn't mean anything, most compilers for most languages do not behave any differently - which is exactly why few projects use those directly instead of using some more capable build system. If i want to, e.g., parse an XML file and generate some code from it and the Go tools (or whatever) doesn't allow for that, i'm not going to not do that, i'm going to write a `build.sh` script (or use some more capable build system, like premake or whatever) that does exactly what i want. Go (or whatever) didn't made anything more secure here, it just kicked the can down the road for someone else to pick it up so it wont have to - but the can still needs to be picked up regardless.
- gpderetta 2y ago
  There is a difference between actually building a project and merely opening a file in an IDE though. See for example the recent emacs completion vulnerability [1], which AFAIK is still open. [1] https://nvd.nist.gov/vuln/detail/CVE-2024-53920 https://nvd.nist.gov/vuln/detail/CVE-2024-53920.

mpalmer 2y ago

Syscalls aren't available to comptime code

actionfromafar 2y ago
Also see e.g. https://github.com/rust-lang/rust-analyzer/issues/14375 https://github.com/rust-lang/rust-analyzer/issues/14375

badsectoracula 2y ago

Considering that pretty much every non-toy project isn't built by directly calling the compiler but through build tools like make, cmake, autotools, etc or even scripts like `build.sh` that can call arbitrary commands and that even IDEs have functionality to let you call arbitrary commands before and after builds (and had since the 90s at least), i do not see this as a realistic concern worth of limiting a language's functionality.

adonovan 2y ago
Just because most projects’ builds have large attack surfaces doesn’t mean we should accept that. The build and IDE tooling for Go does not trust the code it consumes.
- badsectoracula 2y ago
  That doesn't mean anything, most compilers for most languages do not behave any differently - which is exactly why few projects use those directly instead of using some more capable build system. If i want to, e.g., parse an XML file and generate some code from it and the Go tools (or whatever) doesn't allow for that, i'm not going to not do that, i'm going to write a `build.sh` script (or use some more capable build system, like premake or whatever) that does exactly what i want. Go (or whatever) didn't made anything more secure here, it just kicked the can down the road for someone else to pick it up so it wont have to - but the can still needs to be picked up regardless.
gpderetta 2y ago
There is a difference between actually building a project and merely opening a file in an IDE though. See for example the recent emacs completion vulnerability [1], which AFAIK is still open. [1] https://nvd.nist.gov/vuln/detail/CVE-2024-53920 https://nvd.nist.gov/vuln/detail/CVE-2024-53920.