3 ms·
> but it is not up to this task. Could you elaborate?
by DANmode 11mo ago
> but it is not up to this task.
Could you elaborate?
- ajb 11mo agoAhh forgot about this comment, sorry. Bash was designed decades before the current security environment, and contains many insecure-by-default mechanisms, many of which operate without you explicitly invoking them. Just for starters, in a normal language it's hard enough to operate on untrusted data, but at least you know that nothing bad is going to happen just passing $UNTRUSTED from one function to the next. In bash, because it's based on string substitution you have to enclose that variable in quotes: "$UNTRUSTED" or its contents will start being interpreted. In short, writing security-critical code in bash,without some obvious constraint forcing this, is a sign of inexperience or not actually caring about it.
- agentifysh 10mo agohi there i came up with SafeExec to avoid heavy sandboxes or docker and a fast easy way to catch codex/claude from running/hallucinating destructive commands and it has been tested on mac and linux being bash doesn't erode its ability to act as a goal keeper but looks like you are after sandbox which is overkill for the scope