We printed a JS object where the signing key goes

For some period ending today, /leaderboard printed this in its provenance line:

signature [object Object]

signature is an object — {keyid, alg, sig} — and the page interpolated the whole thing into text. JavaScript stringifies an object as [object Object], and there it sat.

In isolation this is a cosmetic bug, the kind every site ships occasionally. It is not in isolation. It was in the paragraph whose entire job is to tell you that you do not have to trust this page — that the board is signed, that the key is published, and that you can check both yourself. Of all the sentences on this site, that is the worst one to render a JavaScript artifact into. It reads exactly like a project that talks about verification without doing any.

The signature was fine the whole time

Worth stating plainly, because “the signature line was broken” invites a worse conclusion than the truth. The cryptography was never affected:

• sha256 of the published public key is 8d62aa33ed5162f3, which matches the keyid on /verification, the keyid inside leaderboard.json, and the value the docs tell you to expect.
• The Ed25519 signature over the DSSE pre-authentication encoding verifies valid against that key.
• Changing a single number in the payload and re-verifying returns invalid, as documented.

The chain was sound end to end. Only the rendering of it was wrong — which is its own kind of bad, since the rendering is the part a reader actually sees.

What we changed

The page now prints the algorithm, the full key id, and a truncated signature with a link to the complete artifact. The key id is deliberately not shortened: it is the one value a reader compares against their own provael leaderboard verify output, so truncating it would remove the reason it is on the page.

The more useful change is the check. [object Object] in built output is never correct — it is always an object that escaped into a text node — so the build now fails if that string, or any [object X], appears in any rendered page. It cost four lines and it would have caught this before it shipped.

It is scoped to HTML, Markdown and text output, and deliberately not to JavaScript bundles, where Object.prototype.toString.call(x) === '[object Object]' is a completely ordinary type check. A check that fails the build on a correct dependency gets disabled within a week, and then it is worse than not having written it.

The part that annoys us

This same paragraph has now mis-rendered its own signature state twice. The first time, the copy was hardcoded to say the board was unsigned while only the value beside it was dynamic — so the moment the board was genuinely signed, the page announced “The payload is unsigned” next to a valid signature. There is a comment in the source about that one, four lines above the line that broke this time.

The lesson we took from the first occurrence was to make the prose dynamic. The lesson available now is narrower and more useful: a comment explaining a past bug does not prevent the next one, and we had written a comment instead of a check. The check exists now.