A NUL byte truncated on read broke Chron's 14,994-message hash chain

The rows were minutes old and the importer was their only writer, so the suspect list was short ^[4]. The developer started with ordering. Imported transcripts keep the client's line order, because 11,591 lines in the corpus carry a timestamp earlier than the line before them, and a wrong sort would link the chain in the wrong sequence ^[6].

Chron's verifier is well built on this point. It reports a prev_hash mismatch when rows are out of order, and a content_hash mismatch when a row's stored hash disagrees with that row's own stored fields ^[7]. Row 8842 failed the second check ^[3].

That failure should have been impossible. The import code hashes a string and inserts the same string a few lines later, in the same function ^[8]. A query on the row found 298 characters, 530 bytes when cast to a blob, and a NUL at position 299 ^[9]. The write hashed all 530 bytes. Verification hashed what the driver returned: 298 characters in 308 bytes ^[11]. The read path dropped 222 bytes ^[12]. The NUL came from tool output, printed by some program in some session ^[13].

"For a tool whose entire job is telling you whether a record was altered, a false positive is worse than a missed detection. A missed detection is a gap. A false positive teaches people to ignore the alarm," the developer wrote ^[5]. Chaining raises the cost of that alarm. One byte in one row out of 73,526 invalidated a 14,994-event chain, because every row after it inherits the break ^[14].

The obvious fix is to strip the NUL inside the hash function. It fails. The stored value still holds the NUL, so the writer hashes the sanitized original while the verifier hashes the sanitized truncation ^[15]. "You have to change what goes into the database, not just what goes into the digest," the developer wrote ^[15]. The rule that came out of it is "hash what you can read back" ^[16]. I think the rule is correct for any design that hashes before it stores. A verifier only ever sees what the read path returns. The diagnostic query also shows the bytes were never lost in storage: the blob cast still counted 530 ^[9].

The reproduction covers one stack, @libsql/client 0.17.3 on Node 23 ^[18]. The 6 characters it returned are the word "before", everything ahead of the NUL ^[19]. The harness also writes lone high and low surrogates, a valid emoji pair, CRLF with a tab, and ESC with DEL ^[17]. The post's printed output shows the NUL result only ^[20]. For this failure to transfer to another system, its driver has to hand TEXT back as a string that ends at the first NUL. The harness is short and needs only the libsql client and Node's crypto module ^[17].