Our favorite operating system is now changing the default shell (ksh) to enforce not allowing invalid NUL characters in input that will be parsed as parts of the script.
↫ Undeadly.org
As someone who doesn’t deal with stuff like this – I rarely actively use shell scripts – it seems kind of insane to me that this wasn’t the norm since the beginning.
You’d have to understand that these shells and the scripts they (mostly) run were under a Unix security mentality of anyone on the computer has or should have access to everything, and if they do something bad that crashes it we’ll revoke their user permissions, and spare compute to do a sanity check of files wasn’t really a thing.
Agreed. UNIX was also built to run on what we would now consider to be some pretty weak hardware. Parsing and processing that did not have to be done was not being done. As you say, the user and programmer were expected to take a certainly level of responsibilty.
But it was certainly an entirely different “security” reality. We have always had to worry about errant input causing stability or performance problems. What we did not always have to worry about was these kinds of things becoming attack vectors for the bad guys (or the first small step of many that turns a series of individually harmless oversights into attacks horrific in scope and scale). We certainly did not need to worry about them doing it from their living room or basement on the other side of the world. That is of course why OpenBSD cares about it.
> were under a
“were” being 30+ years ago…
30? Pffffffffffffffffffffffffffffffffffff-fing-fffffffffffffft!!!! try 50+ years ago. My comment was in relationship to Thom’s questioning of why it was ever that way. Different design constraints. Different security model. Thats no excuse for not doing it sooner. Seriously, openbsd, why not in Openbsd 0.0.1? But the vi vs emacs war was often won by vi because it was smaller and could fit on lower end systems storage. And that was *much later* than the design of the shells.