4 ms·
Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.
by sleavey 5y ago
Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.
- wowaname 5y agoYou have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.
- sleavey 5y agoDo you want to first find that out when you're under duress? Sensible defaults matter.
- wowaname 5y agoAre you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.
- sleavey 5y agoAs I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.
- wowaname 5y agoI'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.