Xz: Can you spot the single character that disabled Linux landlock?

What the stray character does

• The CMake script used check_c_source_compiles on an inline C snippet to decide whether to enable Landlock.
• A single extra . inside that snippet makes it invalid C, so the test always fails.
• Result: Landlock support is silently never enabled via CMake, while the build as a whole still succeeds.
• Autotools did not have this same bug; only the CMake-based detection was sabotaged.

Build systems, feature detection, and fragility

• Many commenters explain that autoconf/CMake commonly probe features by compiling tiny programs and treating “compile succeeds” as “feature available.”
• This pattern is powerful for portability but fragile: any syntax error or environment quirk can silently disable features.
• Several argue these checks should distinguish expected failures (e.g., missing syscall) from generic syntax errors and fail hard on the latter.
• Others note that compilers and systems are too heterogeneous to reliably parse and classify all failure modes.

Testing, CI, and configuration policies

• Some argue security features should never be auto-disabled: if explicitly requested and not available, configuration should fail loudly.
• Others say hard-failing on optional features makes software unusable in diverse environments; “enable if available” is common and sometimes necessary.
• Suggestions:
  • Add explicit tests that verify Landlock (or similar features) actually works on at least one known-good system.
  • Use fake headers or mock implementations in tests to verify build-system logic separately from real system headers.
  • Provide tri-state options (force-enable, auto-detect, force-disable).

Landlock and security impact

• Thread notes that disabling Landlock in xz is not directly needed for the already-exposed sshd backdoor, suggesting it may have been preparation for other exploits or defense-in-depth removal.
• Some see this as part of a broader pattern of weakening sandboxing and security checks in the project, not an isolated “bug.”

Tooling, Unicode, and whitespace issues

• Participants discuss how easy it is to hide malicious changes:
  • Tiny punctuation changes in dense diffs.
  • Unicode confusables in identifiers.
• Various mitigations are proposed:
  • Compiler flags warning on mixed scripts or non-ASCII identifiers.
  • IDEs/diff tools that highlight suspicious characters and whitespace.
  • AST-aware or structured diffs, though strings and macros make this hard.

Governance and supply-chain concerns

• Commenters highlight that a single highly trusted maintainer (or co-maintainer) could make large, security-sensitive changes with little scrutiny.
• There is concern that similar long-term infiltration could exist in other foundational projects, and that current review practices often focus on surface-level diffs rather than deeper threat modeling.