Heads-up: next release will re-upload one-time keys on almost every sync (matrix-js-sdk bug with crypto-wasm ≥ 18.5.0) #1960

Describe the bug

Hi!

I'm working on another Matrix web client built on matrix-js-sdk, and I ran into a nasty E2EE bug there that I think Sable is about to ship too — hence this heads-up rather than a report of something I've observed in Sable itself.

matrix-js-sdk passes an empty one-time-key count to the rust OlmMachine when it processes to-device messages and device-list changes. Since @matrix-org/matrix-sdk-crypto-wasm 18.5.0 an empty count means "the server has no one-time keys", so the client uploads a fresh batch of 50 keys on almost every sync. The server's stock grows without bound (we measured 20k keys on a single device), and since vodozemac only keeps the private half of the most recent ~100 keys, peers who claim an older key can no longer open an Olm session with the device. Symptom for users: new DMs / rooms with them never decrypt (MEGOLM_UNKNOWN_INBOUND_SESSION_ID), while existing conversations keep working — which makes it very hard to attribute.

Full analysis: matrix-org/matrix-js-sdk#5501
Fix: matrix-org/matrix-js-sdk#5502 (under review)

Why I think Sable is affected: pnpm-lock.yaml on dev resolves matrix-js-sdk@42.1.0 with @matrix-org/matrix-sdk-crypto-wasm@18.5.0, which is exactly the combination that triggers it. The released v1.21.0 still resolves 18.3.1 and is fine. It's the same one-time-key count plumbing that bit you in #1075 (there the count was lost, here it's asserted as zero).

Reproduction

On a dev build, sign in and leave the client idle with the browser devtools open, network tab filtered on keys/upload: you should see a POST with exactly 50 one_time_keys on most syncs that carry to_device events or device_lists changes. If you have access to the homeserver, device_one_time_keys_count in /sync responses climbs steadily (50 → 100 → 150 …) instead of staying flat.

Expected behavior

One batch of one-time keys at startup, then top-ups only as keys are claimed.

Platform and versions

- Sable `dev` (not released yet): `matrix-js-sdk` 42.1.0, `@matrix-org/matrix-sdk-crypto-wasm` 18.5.0 → affected
- Sable v1.21.0: `matrix-js-sdk` 42.0.0, `@matrix-org/matrix-sdk-crypto-wasm` 18.3.1 → not affected
- Affected wasm versions: 18.5.0 and 18.6.0; 18.4.0 is not

Additional context

Until the js-sdk fix is released, the simplest protection is to pin the binding in package.json:

"pnpm": { "overrides": { "@matrix-org/matrix-sdk-crypto-wasm": "18.4.0" } }

No re-login is needed and the crypto store survives the downgrade. Note that pinning heals nothing already published: a device that has been over-uploading needs its server-side key stock trimmed to the newest ~50 before peers can start sessions with it again. Happy to share more details if useful.