Skip to main content

Module storage_conformance

Module storage_conformance 

Source
Expand description

A portable conformance suite for MlsStorage implementations.

Every binding hands the SDK its own MlsStorage: the Keychain on iOS, an encrypted preferences file on Android, the platform credential store in Python, and whatever a Rust host wires in. Each is a promise that bytes stored under (key_type, key_id) come back whole, that categories do not bleed into each other, and that an overwrite replaces. Nothing checks the promise: an implementation that returns Ok from every method can still drop an overwrite, split a key id on the : a session id carries, or truncate a ratchet tree, and the symptom arrives much later as a group that cannot decrypt.

Green here is the definition of “this backend honours the trait contract”. It is not a persistence test: every check runs against one open instance, so a backend that forgets everything on reopen, or that acknowledges a write it has not made durable, can still be green. A persistent backend proves those with a reopen test of its own.

The suite writes only under its own probe key types and deletes only what it wrote, provided the backend keeps key types apart. That is why key-type isolation is checked first, with point writes and point deletes of ids nothing else uses, and why a failure there ends the run before any listed delete: on a backend that merges categories, listing a probe key type names the identity too. One check cannot be made safe in advance. clear_type has to be called to be tested, and a backend that clears every category takes the real records with it. Probe a new backend on a scratch instance until it is green; after that it is safe to run against a live store.

The report type is shared with the protocol-state suite in the engine crate, which re-exports it, so the two suites render one JSON shape: {"passed":[...],"failures":[{"check","detail"}]}.

Structs§

ConformanceFailure
One failed check.
ConformanceReport
The result of running a suite against one backend.

Constants§

CONFORMANCE_KEY_TYPE
The key type every probe record is written under.
CONFORMANCE_KEY_TYPE_OTHER
A second key type, used to prove categories do not bleed into each other.
LARGE_RECORD_BYTES
The largest value the suite writes.

Functions§

run
Run the suite.
run_json
Run the suite and render the report as JSON.