Versions are dates now: v{yy}.{m}.{d}, so v26.9.4 is 2026-09-04.
This ships whenever something is learned — the surface changed five times today —
and a semver number would advertise a compatibility contract nobody is
maintaining. A date claims only what is true: the state of the thing on the day
it was cut. Earlier tags (v0.1.0, v0.2.0) are left alone rather than
rewritten; CalVer sorts after them.
The fix in this cut
Setting a passphrase on production failed:
Pbkdf2 failed: iteration counts above 100000 are not supported (requested 210000)
210,000 is OWASP's 2023 floor for PBKDF2-HMAC-SHA256. bun accepts it, all 128
tests passed, and workerd caps deriveBits at 100,000 — so no test could
have caught it. Same shape as the aot: false bug already documented in
app.ts: correct code, green suite, and a failure that exists only on the
runtime that serves users.
It failed closed, which is the one good thing: the change was refused, the
old passphrase kept working, nothing was half-applied.
What the lower count costs, measured rather than asserted — on one core:
| stored as | per guess |
|---|---|
| bare SHA-256 (what OAuth tokens use) | 0.0009 ms |
| PBKDF2 @ 100,000 | 5.74 ms — 6,378× slower |
You pay 5.74 ms once per login; an attacker pays it per guess. Halving the
iterations halves their cost, and the mitigations that actually carry the load
are elsewhere: /login and /authorize allow five attempts then exponential
backoff, so an online attack never reaches the hash's margin, and an offline
attack means D1 has already leaked. The stored format carries its own iteration
count, so raising this the day workerd does costs nothing — existing hashes keep
verifying at the count they were written with.
/health and the page footer report the version, so a running deployment always
names its own build.
Everything else is unchanged from
v0.2.0 —
that release has the screenshots and the full tour.
MIT.