*sshole, or when are we going to get rid of C?

A collision between two uses of the same string sentinel can turn an SSH password check into an authentication bypass. On Unix, “ ” has long represented a locked account; since 2012, musl libc’s crypt function has also returned that value when a password is too long to hash. Because sshd hashes login attempts for locked accounts to reduce timing leaks, the collision can let an unauthenticated user obtain a shell - potentially as root - on systems using musl without PAM, including the official Alpine AWS image. This is not a memory-safety bug: it arises from error signaling. POSIX specifies that crypt should return null and set errno on failure, but C cannot force callers to check. Musl adopted the sentinel after seeing binaries ignore the specified error return. By contrast, Rust’s Result types make errors explicit and require callers to handle them.

The broader argument is that programming languages shape engineering norms as well as individual code. Rust communities tend to encode invariants and errors in types, while C practices permit ambiguous in-band signals. This matters even when code is generated by AI agents: agents draw on libraries and examples shaped by their language communities, so Rust can preserve safeguards that a switch to C would discard. Claims that agents make C or assembly equally rigorous overlook this accumulated culture and trust a less deterministic process despite available alternatives. Build speed and portability are genuine costs of Rust, but resisting Rust dependencies solely to preserve existing practices may put maintainers’ preferences ahead of users’ interests.