Iteration 24 closes, absorbing 31 and 34. No code in this commit. - stories 24, 31, 34 -> `status: done`, each with a landing banner. 24's records the gate numbers and BOTH disclosed deviations: monitor takes three arguments (the caller may be `main`, which has no mailbox) and a v1 `call` reply is a typed scalar (which is what let the agreement be checked at compile time, WO-E226). 31's notes it landed INSIDE 24 and that a fifth mechanism it never anticipated came out of proving the gate — the drain guarantee (40). 34's names the gap it did NOT close: still no RNG, so CSRF/sessions stay blocked - board: in-progress row cleared, marker doc deleted (convention), the standup entry in the six-question shape, chain note — next link is databasev2 4 (io_uring group-commit, chain 5) - graph: PUBSUB2 (pub/sub + WebSockets, "rejected until here") -> done - porch ledger: a WebSocket/pub-sub row added; the cancellation row now says what it actually waits on rather than repeating "the arc"; the README's "no WebSockets/SSE" limitation was stale — WebSockets are supported, SSE and chunked encoding are not - CODE-LOGIC: runtime/src gains the actor-lifecycle section (call, death, the cap counter's sender/home-thread split, the monitor walk, the timer list), the drain guarantee, and the digest section; docs/examples/chat gains its own — actor topology, WHY two actors per connection, fd ownership, and the shutdown choreography Battery after the doc edits: wovm-test 36 suites 0 fail, woc-test exit 0, oop-e2e 119/0, chat 11/0, web-app 46/0, linkcheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.5 KiB
| iteration | status |
|---|---|
| 34 | done |
Iteration 34 — crypto builtins: digests and HMAC in the runtime
Format:
product/story-iteration-template. Part of Story — one language, one runtime, one database, one binary.Inserted 2026-08-22 — the framework ledger's oldest unowned gap gets an owner. PREMISE UPDATE (same day, post-merge): iteration 36 landed bitwise
& | ^ << >>+ hex literals, so digests ARE now expressible in pure.wo— the original "no bitwise" impossibility is gone. The fork is now a real choice for this story's brainstorm: hand-rolled C builtins (bounded, fast, libc-only doctrine permits) vs pure-.wo(no runtime surface growth; interpreter-speed hashing). Off the concurrency chain but gates chain position 4: iteration 24's WebSocket handshake needs SHA-1 before chat can land.
✅ LANDED 2026-08-27 — inside 24 as its task 1. The fork resolved to C builtins:
sha1(85),sha256(86),hmac_sha256(87), each over one buffer returning a freshBytes. Pinned to the published vectors — RFC 3174, the SHA-256 vectors, RFC 4231 — inruntime/test/test_crypto.c, 18 checks, plus a corpus fixture hashing "abc" from.wo. This unblocked chain position 4: the WebSocket handshake needs SHA-1, andjust chatverifies the accept-key independently.The gap it did NOT close: there is still no RNG in the runtime. HMAC authenticates a token and cannot mint one, so CSRF and sessions stay blocked — which is why 39 leads with a random-bytes builtin rather than treating them as unblocked.
Why this iteration exists
Four consumers already wait on it, none able to proceed:
iteration 24's upgrade handshake
(Sec-WebSocket-Accept = base64(SHA-1(key + GUID)) — SHA-1
specifically, not a choice); the framework's ETag/conditional-request
row (wants a content hash); HMAC-signed tokens the auth core can grow;
and held databasev2 10, whose
challenge–response needs primitives that "do not exist" (its demotion
note). Bytes and base64 landed with iteration 19 — the carriers exist,
only the digests are missing.
Goals
- Digest builtins over Bytes: SHA-1 (the WS handshake's hard
requirement), SHA-256 (the modern default for ETag/HMAC), each
Bytes -> Bytes, streaming not required (whole-value, like every existing builtin). - HMAC-SHA256 (
key: Bytes, msg: Bytes -> Bytes) — the one composition real services need (signed tokens, webhook signatures); expressible in.wosince iteration 36's bitwise set — C-builtin vs pure-.wois this story's brainstorm call. - Test vectors are the acceptance: FIPS 180 / RFC 2202 / RFC 4231 vectors in a corpus fixture — a digest that "looks right" is worth nothing.
- The contract doc row: names, arities, Bytes-in/Bytes-out, and the explicit note that SHA-1 exists for protocol compatibility (WS), not for new designs.
Acceptance Criteria (draft — the spec refines)
- Given the published test vectors for SHA-1, SHA-256, and HMAC-SHA256, when the corpus fixture runs them through the builtins, then every output matches byte-for-byte (via the existing base64/Bytes surface).
- Given the WS handshake's worked example from RFC 6455
(
dGhlIHNhbXBsZSBub25jZQ==→s3pPLMBiTxaQ9kYGzzhZRbK+xOo=), when composed in pure.wofromsha1+base64_encode, then the exact accept token comes out — iteration 24's handshake is provably one expression away. - Given the full battery, when it runs, then nothing
regresses — new builtin ids only, no opcode, no
.wobversion bump (the iteration-19/time.ticksprecedent).
Out Of Scope
- Asymmetric crypto (ed25519 signatures/keypairs) — held iteration 21's spec decides what it needs when it unholds; this iteration lays the digest floor it will stand on.
- TLS — permanently the proxy's job (framework doctrine).
- CRC32 — the ledger lists it, but no consumer is blocked on it; it joins only if 24's spec finds a real need (rejecting speculative surface).
- A password-hashing story (bcrypt/argon2) — no workload asks yet.
- Bitwise operators in the language — a separate, bigger surface decision this iteration deliberately routes around.
Info
Forks the spec must settle:
- The namespace. The reserved stdlib namespaces are exactly
fs/proc/net/time/json/env(compiler-enforced list) — a newcryptonamespace touches that list plus the typechecker table, or the functions ride an existing namespace. Leaning: a realcryptonamespace (the list exists to be grown deliberately; this is deliberate). - Surface shape:
crypto.sha1(b: Bytes) -> Bytes,crypto.sha256(b: Bytes) -> Bytes,crypto.hmac_sha256(key: Bytes, msg: Bytes) -> Bytes— Text convenience overloads rejected (the caller hasbytes_of_text). - Implementation source: hand-rolled C from the FIPS pseudocode (~200 lines for both digests; well-trodden, vector-verified) — the doctrine's shape. No linking against OpenSSL, ever.
- Where the code lives:
runtime/src/crypto.cbeside sysio, or inside builtin.c — file layout, the executor decides.
Proposed Solution
Brainstorm → (small) spec settling the four forks → implement with the
time.ticks slice's shape (ids, one table row per compiler surface,
contract-doc rows, vector fixtures). Lands any time before iteration
24's spec; independent of 31/22/23.