5 ms·

If you're compiling malicious code, haven't you already lost? I don't see how preventing pointer manipulation at compile time (or anything else, really) improv

If you're compiling malicious code, haven't you already lost? I don't see how preventing pointer manipulation at compile time (or anything else, really) improves security unless people never run the executable they compiled.

WalterBright 5y ago
People expect to check source code before running it. They do not expect to have to check it before compiling it. Malware works by taking advantage of peoples' expectations.
- SubjectToChange 5y ago
  People expect to check source code before running it. They do not expect to have to check it before compiling it. Why are they compiling untrusted code? To see if it's syntactically correct? If the code you're compiling is using a build system, you're already compromised. Compilation of untrusted code should always be sandboxed, regardless of compile-time programming capabilities.
- gpderetta 5y ago
  Given the way modern IDEs work, unrestricted compile time evaluation would make it dangerous to even open potentially malicious code.
lalaithion 5y ago
It means that you need to do $ sandbox "foobarc malicious.foobar -o executable && ./executable" instead of $ foobarc malicious.foobar -o executable $ sandbox ./executable Which isn't totally intuitive.
- WalterBright 5y ago
  Yes, I don't really want to have to recommend to people that they have to run the compiler in a sandbox.
- SubjectToChange 5y ago
  And what if you are compiling more than a single file? What if the project or library you are compiling uses make/cmake/gn/etc? The point is that restrictions on compile-time programming only protect you in trivial cases. And I can't think of many reasons to fully compile code without the intent of running the executable.
  - usefulcat 5y ago
    Testing. If you wanted to test that your compile-time code is correct, I'd imagine the typical--if not only--way to do that would be to compile it. Certainly that's true for constexpr in c++.
    - johannes1234321 5y ago
      you could compile it to verify, but you usally compile it using a build system to set include paths right etc. that build system could include a `rm -rf $HOME 2>/dev/null` or similar already.
    - SubjectToChange 5y ago
      Testing code requires executing it. This is true for compile-time code or run-time code.
      - WalterBright 5y ago
        Quite a lot of the tests in the D compiler suite are compile time only. It makes for running the test suite much faster. To test ImportC, which inherits D's ability to execute functions at compile time, I've been using a lot of _Static_assert() constructs. https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e2ac8ad3353ee43/test/compilable/testcstuff1.c#L131 https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e...
  - WalterBright 5y ago
    If you want a compiler that is designed to enable ransomware injection into your system merely by compiling a file, that's fine with me. But it won't be D.
junon 5y ago
Do you audit every repository you clone and build?

WalterBright 5y ago

People expect to check source code before running it. They do not expect to have to check it before compiling it. Malware works by taking advantage of peoples' expectations.

SubjectToChange 5y ago
People expect to check source code before running it. They do not expect to have to check it before compiling it. Why are they compiling untrusted code? To see if it's syntactically correct? If the code you're compiling is using a build system, you're already compromised. Compilation of untrusted code should always be sandboxed, regardless of compile-time programming capabilities.
gpderetta 5y ago
Given the way modern IDEs work, unrestricted compile time evaluation would make it dangerous to even open potentially malicious code.

lalaithion 5y ago

It means that you need to do $ sandbox "foobarc malicious.foobar -o executable && ./executable" instead of $ foobarc malicious.foobar -o executable $ sandbox ./executable Which isn't totally intuitive.

WalterBright 5y ago
Yes, I don't really want to have to recommend to people that they have to run the compiler in a sandbox.
SubjectToChange 5y ago
And what if you are compiling more than a single file? What if the project or library you are compiling uses make/cmake/gn/etc? The point is that restrictions on compile-time programming only protect you in trivial cases. And I can't think of many reasons to fully compile code without the intent of running the executable.
- usefulcat 5y ago
  Testing. If you wanted to test that your compile-time code is correct, I'd imagine the typical--if not only--way to do that would be to compile it. Certainly that's true for constexpr in c++.
  - johannes1234321 5y ago
    you could compile it to verify, but you usally compile it using a build system to set include paths right etc. that build system could include a `rm -rf $HOME 2>/dev/null` or similar already.
  - SubjectToChange 5y ago
    Testing code requires executing it. This is true for compile-time code or run-time code.
    - WalterBright 5y ago
      Quite a lot of the tests in the D compiler suite are compile time only. It makes for running the test suite much faster. To test ImportC, which inherits D's ability to execute functions at compile time, I've been using a lot of _Static_assert() constructs. https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e2ac8ad3353ee43/test/compilable/testcstuff1.c#L131 https://github.com/dlang/dmd/blob/a5b16bd8e72a447d509cca862e...
- WalterBright 5y ago
  If you want a compiler that is designed to enable ransomware injection into your system merely by compiling a file, that's fine with me. But it won't be D.

junon 5y ago

Do you audit every repository you clone and build?