OpenBSD now enforcing no invalid NUL characters in shell scripts

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.