fix(svix): accept space-separated multi-signature headers

[canuto]

The bug

Svix sends every signature it holds during a signing-secret rotation, separated by spaces:

svix-signature: v1,<old> v1,<new>

Only one matches the secret the receiver has, and the message must be accepted on that one.

svix.verify split the combined string on commas alone:

const parts = signature.split(',');
if (part === 'v1' && i + 1 < parts.length) { signatures.push(parts[i + 1].trim()); i++; }

So v1,AAA v1,BBB,t=…,id=… becomes ['v1', 'AAA v1', 'BBB', 't=…', 'id=…']:

• the first signature is captured as the literal string AAA v1 — corrupted, never matches
• BBB is skipped entirely, because the element before it is AAA v1, not v1

Result: every signature fails for the whole duration of a rotation. It affects svix and clerk, which delegates to it.

Reproduced before fixing:

single signature            -> true
rotation: good then other   -> false      ← a valid signature, rejected
rotation: other then good   -> false

The fix

The provider's own doc comment already documented the correct format:

 * For this library, pass signature in format: "<svix-signature>,t=<timestamp>,id=<msg-id>"
 * ... or multiple sigs "v1,<sig1> v1,<sig2>,t=...,id=..."

So the intent was right and only the parse was wrong. Split on commas and whitespace:

const parts = signature.split(/[,\s]+/);

Base64 contains no whitespace, so this cannot split a signature in half. Single-signature headers parse exactly as before.

Why it survived

Every existing svix and clerk test used a single signature — generateSvixSignature only ever produces one — so the multi-signature branch the comment describes had no coverage at all.

Added six tests:

test	what it pins
matching signature first	the corrupted-first-element case
matching signature last	the dropped-later-elements case (fails for a different reason than the above)
matching signature among three	more than one separator
none matching → false	stops a parser that blindly accepts any multi-sig header from passing the three above
stale timestamp → false	tolerance still applies when several signatures are present
through the headers object	getSignature() is the path Clerk actually takes; the old tests passed a pre-joined string and bypassed it

Verification

• npm test — 117 pass, 0 fail
• Mutation-verified: restoring split(',') fails exactly the four acceptance tests and leaves the two rejection tests passing. A fix with no failing mutation would mean the tests prove nothing.

Found by

Using this package in snill to replace a hand-rolled Clerk verifier (RestDB/snill#1647 — an unsigned webhook handler that had been shadowing the verified one). Snill works around it by passing one signature at a time; once this ships it can pass the header straight through.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mkd9oGgdMEFUftzCeiCfZw