OpenBSD now enforcing no invalid NUL characters in shell scripts

Original Article ↗ Hacker News Discussion ↗

OpenBSD is tightening its shell behavior by rejecting NUL bytes in the parsed portions of shell scripts, aiming to eliminate ambiguous or unsafe input while still allowing arbitrary binary data appended after the executable part of a script. Commenters generally welcome the change as a security and robustness improvement, contrasting it with older “be liberal in what you accept” Postel-style thinking and noting how permissive parsing has led to bugs and exploits in other contexts. Some raise concerns about compatibility with tools like cosmopolitan libc or self-extracting archives, but others argue such edge cases should adapt by encoding binary data rather than relying on undefined behavior.

Scope of the OpenBSD Change

  • OpenBSD’s ksh now rejects NUL characters in any part of a shell script that is parsed or in history files.
  • Arbitrary bytes are still allowed after the executable script portion (e.g., at the tail of a file), but not in the middle of parsed script text.
  • The change shipped in snapshots for ~2 months and only broke one test program that implicitly relied on the old behavior.

Impact on Self‑Extracting Scripts and Binary Embedding

  • Classic self‑extracting shell+tar/shar mechanisms are mostly unaffected:
    • Appended payloads after exit or script end remain valid.
    • Traditional shar archives encode binary (uuencode/base64), avoiding NULs entirely.
  • Concern that some self‑extracting hybrids will break:
    • Cosmopolitan/APE binaries are repeatedly cited as likely affected because they embed NULs near the start of the file, inside the region ksh would parse.
    • Several commenters argue that bending historic shell behavior to support such esoteric hybrids is a bad tradeoff.
  • Some note this makes OpenBSD a good “strict” development platform that surfaces bugs early, even if it diverges from other shells.

Post‑Postel / Robustness vs Strictness

  • The change is framed as rejecting “Postel’s Law” for shells: no longer being liberal in accepting malformed inputs.
  • Many commenters support this shift, saying liberal acceptance:
    • Increases security risk and long‑term fragility.
    • Forces implementations to support quirks forever, harming interoperability.
  • Others argue that refusing malformed input gracefully is still compatible with the spirit of Postel’s principle.
  • HTML’s permissive parsing, TCP robustness, and newer documents criticizing Postel’s Law are cited as context for this “post‑Postel” mindset.

Related Filename & Parsing Hazards

  • Discussion broadens to Unix’s permissive filename rules:
    • Newlines, spaces, and option‑like names (--help) can break naive scripts, especially those that parse ls output.
    • Safer patterns include globbing, find -print0 + xargs -0, and strict quoting.
  • Some wish for filesystem‑level restrictions (e.g., forbidding “dangerous” characters), while others favor keeping POSIX’s generality and handling hazards in higher layers.

Other Side Topics

  • Questions about mksh availability (Android shell) and TLS/legal access issues on its site.
  • Brief praise for OpenBSD’s “sanity‑driven” changes, contrasted with other BSDs and Linux distributions.
  • Minor complaints about tone in the commit message and OpenBSD’s continued use of CVS.