There are two reliability constraints that all software faces; security and interoperability. The more lax you are about validation, the more likely interoperability is. "That's weird, I'll just do whatever" is doing SOMETHING, and it's often to the end user's liking. But, you also enter a more and more undefined state inside the software on the other side, and that's where weird things happen. Weird things happening typically manifest as security problems. So the more effort you go to to minimize the possibility of entering a weird state, the more confidence you have that your software is working as specified.
Postel's Law made a lot of sense to me when developing the early Internet. A lot of people were reading imperfect RFCs, and it was nice when your HP server could communicate with a Sun workstation, even though maybe some bit in the TCP header was set wrong. But now? You just gotta get it right and push a hotfix when you realize you messed something up. (Sadly, I don't think it's possible. Middleboxes are getting more and more popular. At work, we make a product where the CLI talks to the server over HTTP/2. We also install Zscaler on every workstation. Zscaler simply blocks HTTP/2. So you can't use our product. Awkward.)
Curious what this is
Fascinating. I wonder what that program is, and why it depends on the NUL character.
Similar to the olde-tyme "-o noexec" and "-o nosuid" options for `mount`, there should be easy, no-exceptions ways to blanket ban other types of simply obvious red-flag activity.
"Unavailable For Legal Reasons - Sorry, no detailled error message available."
http://www.mirbsd.org/mksh.htm
The Android system shell is now abandoned? This is also in rhel9 basesos.
for each $filename in `ls`
loops -- because in many contexts, UNIX treats newlines as a delimiter.Is there any legitimate use for filenames with newlines?
Big oof here. Why? How?
> If there is ONE THING the Unix world needs, it is for bash/ksh/sh to stop diverging further by permitting STUPID INPUT that cannot plausibly work in all other shells. We are in a post-Postel world.
Amem
I mean, it's a good idea, but I wonder what am I missing here. Also what do they mean by post-Postel?
> If there is ONE THING the Unix world needs, it is for bash/ksh/sh to
> stop diverging further by permitting STUPID INPUT that cannot
> plausibly work in all other shells. We are in a post-Postel world.
>
> It remains possible to put arbitrary bytes *AFTER* the parts of the
> shell script that get parsed & executed (like some Solaris patch files
> do). But you can't put arbirary bytes in the middle, ahead of shell
> script parsed lines, because shells can't jump to arbitrary offsets
> inside the input file, they go THROUGH all the 'valid shell script
> text lines' to get there.
So here it is again, an example of OpenBSD making software behavior saner for all of us.
I don't consider use of all caps over a minor issue to be sane behavior. At best it's immaturity (trying to force your point rather than persuade), and at worst it's an emotional imbalance that effects judgement. That said, it's ksh, on OpenBSD, so I couldn't care less what they do.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/shf.c....
And it looks like that covers all parsed parts of the shell script or history file, including heredocs. I get the feeling it's going to break all shar archives with binary files (not that they're particularly common). It will stop NULs being in the script itself, but it won't stop them coming from other sources, e.g.
It remains to be seen if this will be adopted by anyone else, or if it'll be another reason to use OpenBSD only as a restricted environment and not as a general computing platform.> "If there is ONE THING the Unix world needs, it is for bash/ksh/sh to stop diverging further"
> OpenBSD ksh: diverges further