Hacker News Reader

Comment by nafey | Hacker News Reader

Are you familiar with Jai language being developed by Jonathan Blow? What is your opinion on its design?

My opinion is that Jonathan Blow is an amazing developer and he should be joining us on D!

It's been a while since I reviewed the language, and I'd have to re-review it to say anything sane here. But one thing stuck out at me. In D, the support for Compile Time Function Execution (CTFE) is very extensive, and opens the door to a lot of incredible metaprogramming abilities. Jai has this too, but has extended it to allow system calls.

While his demos of programs being run in the compiler is impressive, D doesn't support CTFE system calls for a good reason:

It'll become a vector for malware. People download source code from the intertoobs all the time, and just compile it. Heaven help us if that means your system is now compromised. I'm not going to open that door and make people afraid to compile D code.

It's not worth it.

I assume most people run the code they compile on the very machine they compile it on, so how does preventing compile-time system calls help stop malware?

It means that the D compiler itself is not the doorway for the malware.

Cross-compiling is a common practice, too.

Why not instead alert the programmer that compiling this code would call such-and-such system calls?

That's IMO how all software should work. Apple did something similar, AFIAK, in the latest version of MacOS, and failed - it's obviously something that is extremely hard to retrofit onto existing software. But allowing arbitrary execution for new software, and sensibly limiting it (e.g. "this program cannot access the internet") is, I predict, fairly feasible.

I mean, do those people who download and compile code not then generally... run it...?

Perhaps I'm missing something but the issue here seems to be whether you trust the source, not whether syscalls are made at compile time or run time?

Trusting the compiler, CI/CD pipelines and verifiable builds.

Other languages (such as python) have install-time code execution. When you pip install a library, the library can run arbitrary code and of course has access to anything and everything via the python interpreter. The only thing protecting you is faith in pypi. How is compile-time code execution any different?

> How is compile-time code execution any different?

I don't know the Python ecosystem and so can only speculate. PIP install is not compiling the code, it's an installation program. Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source.

But I'm not going to restrict D to compile only source code from a trusted source.

> Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source.

Nope, unfortunately not, anyone can publish anything to pypi as long as the name isn’t taken. Plenty of room for abuse with typo-squatting, etc.

Reply on news.ycombinator.com