5 ms·
> (p.7) This thesis was written in Typst. Looks good. > The Typst language is Turing-complete, dynamically typed, and not macro-based. It provides capabiliti
by a9h74j 4y ago
> (p.7) This thesis was written in Typst.
Looks good.
> The Typst language is Turing-complete, dynamically typed, and not macro-based. It provides capabilities for user-defined, possibly variadic functions, variables, arrays,
dictionaries (hash maps), and a module system. A Typst file specifies a document that the compiler should set. Typst combines typical markup and scripting/programming elements into a single context-sensitive grammar.
- JadeNB 4y ago> The Typst language is Turing-complete, dynamically typed, and not macro-based. Knuth did a lot right, and some things wrong, when designing with TeX, but I think he has said that he regrets allowing Guy Steele to convince him to make TeX Turing complete, and that makes sense to me. Sometimes I want lots of computing power when typesetting a document, but more often I want to know that I can TeX a document sent to me without worrying that I will be opening myself up to unforeseen exploits. There's a reason that good security involves turning off VBA macros in Office documents from an external source!
- a9h74j 4y agoVery good point. From the website it appears their editing/live-view environment will be browser-based, so that might help.
- tiagod 4y agoSomething 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.
- JadeNB 4y ago> 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 ….
- zokier 4y ago> 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.
- JadeNB 4y ago> > 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.
- zokier 4y agoPoint 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.
- JadeNB 4y ago> 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.)
- azalemeth 4y agoA very large number of academic publishing sites execute arbitrary (La)TeX as part of their online submission process. The general consensus is that it's safe if you disable a number of primitive commands that give broader OS API access, such as "write18" [1], a TeX primitive that gives you shell access. The good thing about pdf(La)TeX is that it's so old that it's pretty damn battle-hardened and I'm unaware of any recent exploits that use it. If you blow up the stack, it notes that you've done so, and dies. I think it has canaries built in, too, but I might be wrong. [1] https://tex.stackexchange.com/questions/20444/what-are-immediate-write18-and-how-does-one-use-them https://tex.stackexchange.com/questions/20444/what-are-immed...