Safety aspect of Nyxt's built-in Lisp REPL?

It’s a copy-and-paste question from #1980. During private communication with Pedro, I think this may be a better platform for this kind of question:

While it’s all nice and cool to have a Lisp REPL inside Nyxt, I was wondering that if an user could arbitrarily evaluate any Lisp codes, would it be potentially unsafe?

I currently do not have any real examples other than evaluating (setf *browser* nil) crashed the browser. I think my thinking may more lean towards this SO question.

1 Like

I don’t think this is a “problem” specific to Nyxt. SBCL happily executed the following input:
(set-macro-character #\( nil), and make the session completely unfunctional.

I think my stand on this can be perfectly summarized into a single sentence by John Shutt:

Dangerous things should be difficult to do by accident [1]

A system that gives a user maximal freedom would likely also give them the freedom to break it. And there are cases when users intentionally want to break the system, for fun or for exploration. Don’t ever try to prevent that.

To prevent breaking the system unintentionally, however, is quite reasonable.

I think the most straightforward solution is to make more internal-ish symbols internal to nyxt. If the user does type in nyxt::, assume they know what they’re doing.

Another alternative is to use package lock facility.

But honestly I don’t think either of the two options above worth it. Maybe it’s good enough to just do a little bit more fool-proof, e.g. declare the type of *browser*. SBCL will then throw an error if you try to set it to nil.

To achieve maximal safeness, one would probably, again, need first-class environment. In MIT Scheme, do (ge (make-top-level-environment)) and you’re mostly safe. First-class environment is almost impossible to simulate shallowly without host language support, though.

[1] Structural insight: Dangerous things should be difficult to do by accident


I’d be worried if loading a Web page could run Lisp code in Nyxt, but a REPL accessible only from an authenticated user account seems like nothing special on a Unix machine.