Hacker News new | past | comments | ask | show | jobs | submit login

> Something being Turing complete doesn't mean much. VBA isn't dangerous because it's Turing complete, it's dangerous because it has APIs that allow it direct access to the host system. You could perfectly well design a system that is not turing complete that would still expose the same kind of vulnerabilities.

You are right that I was emphasising the wrong part of it, in the sense that Turing completeness and security are partially orthogonal: you can be highly non-Turing complete and totally insecure. But you can not be Turing complete and totally secure (essentially Rice's theorem), and that's the point that I meant to make.

My post also may have misrepresented Knuth's concern (sadly, he didn't explain it to me personally, so I don't know). A more practical concern with a Turing-complete markup language, even on an airgapped machine whose security is of less significance, is that you can't guarantee halting, and it doesn't matter how fast your markup language compiles if you feed it a document on which it doesn't halt ….




> But you can not be Turing complete and totally secure (essentially Rice's theorem), and that's the point that I meant to make.

What do you mean by "secure" here?

> A more practical concern with a Turing-complete markup language, even on an airgapped machine whose security is of less significance, is that you can't guarantee halting, and it doesn't matter how fast your markup language compiles if you feed it a document on which it doesn't halt ….

In practice that is less of a problem; you just run the program with some resource limits and timeout, which admittedly turns the system into state machine from pure theoretical viewpoint.


> > But you can not be Turing complete and totally secure (essentially Rice's theorem), and that's the point that I meant to make.

> What do you mean by "secure" here?

Whatever it means to you, literally—you can't decide any non-trivial property of a document in a Turing-complete markup language.


Point I was trying to make is that the types of attacks that can be made purely by computation are very limited, and generally fall in the category of excessive resource consumption, which is something we have fairly decent tools to manage. Or put another way, no amount of computation is going to get a program access to my emails or install rootkit (or whatever) if the runtime does not provide APIs to do so.


> Point I was trying to make is that the types of attacks that can be made purely by computation are very limited, and generally fall in the category of excessive resource consumption, which is something we have fairly decent tools to manage. Or put another way, no amount of computation is going to get a program access to my emails or install rootkit (or whatever) if the runtime does not provide APIs to do so.

My point in turn was that it doesn't matter what APIs the runtime intends to expose, as long as it can be abused accidentally to allow that behaviour. But I guess that, if one doesn't trust the API, then an intended guarantee of circumscribed behavior by the program can't be relied upon either.

(But I think that resource consumption shouldn't be underestimated as an attack! Of course, as you say, it can be mitigated by imposing artificial resource limitations, but, as you said earlier, that's not really a solution so much as a renunciation of Turing completeness.)


> as long as it can be abused accidentally to allow that behaviour

That is big if there. Trivial example, canonical brainfuck runtime provides one input and one output stream for the programs; you can easily say with confidence that no brainfuck program is going to open network connections simply because the runtime has no facilities to do so.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: