The canonical envelope names its algorithm: schema_version 3, SHA-384/512 by option, SHA-256 the default

[HackTuah]

The canonical envelope names the digest it is hashed with, in its bytes — so a verifier reads the algorithm from what it holds, not from a page — and SHA-384 and SHA-512 become a host's option beside the SHA-256 default.

What the page claimed before. docs/connectome-canonical.md's rule 9 said "the hash is SHA-256 over exactly these bytes" — the algorithm was prose beside the bytes, the bytes named a schema_version and nothing about a digest, and the code spelled :sha256 at two sites. Moving to SHA-384 would have been a format break announced in a release note.

Now. A fourth fixed top-level member, "algorithm", right after "schema_version": "sha256", "sha384" or "sha512", and the hash is that digest over exactly those bytes — the member is under the hash like every other, so two envelopes of one graph naming different digests are different bytes with different hashes and neither is a rewrite of the other. The diff record gains the same member (its keys sort, so it comes first). schema_version is 3 on the graph and on the diff record; Graph.new/1 refuses 2 as it refused 1 — bytes are produced and hashed here, never re-imported. algorithm: on Canonical.encode/2, hash/2, hash_hex/2, hash_value/2, on Diff.encode/2, hash/2, hash_hex/2, and in the wire surface's host options; SHA-256 when absent, indefinitely; a fourth name refused by ArgumentError before a byte is written. The digest is computed at one site under lib/, the algorithm a variable bound from the option — the key-holding census moves from "two sites, both :sha256" to "one site, no literal". The wire's tools/call result keys the hex by the algorithm's name: sha256 as before under the default.

A verifier holding 0.4.0 or 0.5.0 bytes (schema_version 1 or 2) hashes them unchanged with SHA-256 and compares — those bytes name no algorithm and at those versions the digest is SHA-256 by the page's rule; published hashes stay verifiable forever. The page's Versions section says it in full — read the version; below 3, SHA-256; at 3, the named digest; anything else, refuse — and 0.5.0's goldens are kept in the tree and verified that way by a test. The worked example is given under all three digests, with the SHA-384 bytes shown, so a blind reader reproduces a SHA-384 hash from the page alone.

Two pages: docs/crypto-posture.md (one primitive at one site; three digests named in the bytes; no key, no signature, the seam for a signing package; why the algorithm is under the hash) and docs/fips.md (what a FIPS-mode host needs, in OTP 28's own words — a crypto built with --enable-fips against a validated OpenSSL FIPS provider; the fips_mode configuration parameter in the environment before the crypto module is first loaded, since OTP reads it when the NIF loads; enable_fips_mode/1 deprecated in OTP 28; and OTP's own sentence that a FIPS mode requested but not available fails to load the crypto module, so a release requiring crypto does not boot — and that this package enables none of it and cannot, by the same census; measured on the development runtime, where :crypto.info_fips/0 answers :not_supported, which OTP says names the build). A review lane reproduced every hash on both pages with coreutils alone, and the 0.5.0 goldens as the Versions section says.

Found on the way, by writing the FIPS page's sentence about it: the .app did not require crypto. An HTTP host had it only through plug and bandit, both optional; a stdio-only release built from the .app would have had no :crypto.hash/2 at all. Fixed (extra_applications), pinned by a test that reads the built .app.

Red first — the vocabulary census went red on the @type alone, before any test of the bytes. Twelve mutants over the envelope, zero survivors; three survived a first cut, each a pin that passed for the wrong reason: the diff's non-raising hash/2 hashed with the default over bytes naming SHA-384 while every pin went through hash!/2 (one body now, both forms pinned); the refusal pin proved the string "sha256" was refused, not that strings were (the domain is now generated from algorithms/0 — every other spelling of the three names refused); and the wire surface's diff path had no pin under a non-default algorithm, so a hash under the key sha384 beside bytes naming sha256 — the thing the member exists to prevent — passed 647 tests (pinned; the surface now reads the option once and threads it, so the key and the member cannot come from two reads). A review lane wrote a verifier from the page alone, in Python, and reproduced every hash on the page and every golden. Gate on the head: thirteen pass. 11 properties, 649 tests, 0 failures — 626 on main plus twenty-three. Latency stays out of the signed envelope, by decision: a measurement of one machine on one day, not a property of the graph; the unsigned sidecar carries it as before.

How to tell whether you are affected: a consumer that verifies by hashing the bytes it holds is not. A consumer that parses by position or by a fixed member list meets the member in three artefacts, each differently: the graph envelope at the second position, the diff record at the first (its keys sort), the sidecar not at all — but the sidecar's schema_version moves to 3 with the graph's. A host that passes nothing gets sha256 everywhere it did.