Add support for pushing secrets and receiving secret pushes by uhoreg · Pull Request #6164 · matrix-org/matrix-rust-sdk

uhoreg · 2026-02-12T00:29:11Z

Pushing secrets allow devices to send secrets to other devices without waiting for a secret request.

Public API changes documented in changelogs (optional)

Signed-off-by:

codecov · 2026-02-12T00:39:41Z

Codecov Report

❌ Patch coverage is 79.59184% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.80%. Comparing base (29aa3c2) to head (51fc07e).
⚠️ Report is 21 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-sqlite/src/crypto_store.rs	86.88%	2 Missing and 14 partials ⚠️
crates/matrix-sdk-crypto/src/store/types.rs	17.64%	14 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6164      +/-   ##
==========================================
- Coverage   89.81%   89.80%   -0.01%     
==========================================
  Files         376      376              
  Lines      102469   102586     +117     
  Branches   102469   102586     +117     
==========================================
+ Hits        92030    92130     +100     
- Misses       6855     6860       +5     
- Partials     3584     3596      +12

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

codspeed-hq · 2026-02-12T00:50:57Z

Merging this PR will not alter performance

✅ 50 untouched benchmarks

_{Comparing uhoreg:secret_push (51fc07e) with main (cbfecf5)}

richvdh

A couple of initial thoughts.

richvdh · 2026-02-25T10:44:58Z

crates/matrix-sdk-crypto/src/store/traits.rs

+    /// Get all the pushed secrets with the given [`SecretName`] we have
+    /// currently stored.
+    #[cfg(feature = "experimental-push-secrets")]
+    async fn get_pushed_secrets_from_inbox(
+        &self,
+        secret_name: &SecretName,
+    ) -> Result<Vec<SecretPushContent>, Self::Error>;


do we not need to call this in matrix-sdk somewhere? Is that planned for a future PR?

Yes, that is a future PR. I wrote this PR first, then worked on the js-sdk parts, and then worked on the matrix-sdk parts. I could add the matrix-sdk parts to this PR, but I kind of feel like it's cleaner keeping them separate. But I'm not entirely sure, and am willing to be convinced otherwise.

ah, no worries. Could I ask you to try and make that sort of thing clear (e.g. in the description) for future PRs?

crates/matrix-sdk-crypto/src/store/traits.rs

richvdh

also, needs more CHANGELOG.md

rather than a full `GossippedSecret` struct

uhoreg · 2026-03-19T19:51:40Z

I believe this is ready for re-review

richvdh

Various comments.

richvdh · 2026-03-23T12:32:19Z

crates/matrix-sdk-indexeddb/src/crypto_store/mod.rs

-                    keys::SECRETS_INBOX,
-                    (secret.secret_name.as_str(), secret.event.content.request_id.as_str()),
+                    keys::SECRETS_INBOX_V2,
+                    (secret.secret_name.as_str(), secret.secret.as_str()),


why is the secret value used as part of the key?

If we get sent two different secrets for the same name, we need to keep both of them, so that we can check which one is correct.

Speaking of which, I need to add a test to make sure that things don't explode when you receive the same secret twice.

If we get sent two different secrets for the same name, we need to keep both of them, so that we can check which one is correct.

Ah ok. It would be good to note that as a comment somewhere.

richvdh · 2026-03-23T12:42:05Z

crates/matrix-sdk-indexeddb/src/crypto_store/migrations/v104_to_v106.rs

+pub(crate) async fn data_migrate(name: &str, serializer: &SafeEncodeSerializer) -> Result<()> {
+    let db = MigrationDb::new(name, 11).await?;
+
+    // The new store has been made for inbound group sessions; time to populate it.


not inbound group sessions

richvdh · 2026-03-23T12:48:26Z

crates/matrix-sdk-crypto/src/store/types.rs

+    /// The contents of the secret.
+    #[serde(
+        serialize_with = "zeroizing_string_serializer",
+        deserialize_with = "zeroizing_string_deserializer"
+    )]


this is a bit of a pain. I'm not really seeing why we need to implement Serialize for SecretsInboxItem?

Assuming we do need to implement it, it might be cleaner instead to make secret a regular String and then make SecretsInboxItem [#derive(Zeroize,ZeroizeOnDrop)]

richvdh · 2026-03-23T12:52:51Z

crates/matrix-sdk-sqlite/migrations/crypto_store/016_add_new_secrets_inbox.sql

+CREATE TABLE "secrets_inbox" (
+    "secret_name" BLOB NOT NULL,
+    "secret" BLOB NOT NULL
+);


probably needs an index on secret_name

Yeah, probably. I just copied the old schema and forgot about that. The table will likely be small enough that it won't make a difference in practice, but I should add one anyways.

richvdh · 2026-03-23T12:54:07Z

crates/matrix-sdk-sqlite/src/crypto_store.rs

+///
+/// This must be done before creating the store cipher, because the store cipher
+/// requires the `kv` table.
+pub(crate) async fn initialize_store(conn: &SqliteAsyncConn, version: u8) -> Result<u8> {


what is the version argument?

richvdh · 2026-03-23T13:08:54Z

crates/matrix-sdk-crypto/CHANGELOG.md

+- [**breaking**] `CryptoStore::get_secrets_from_inbox` now returns a `Vec` of
+  the secrets as strings, rather than a `Vec` of `GossippedSecret` structs.
+  ([#6164](https://github.com/matrix-org/matrix-rust-sdk/pull/6164))


and Changes has, uh, changed.

Also: newest entries go at the top, in the same way that newest releases go at the top.

richvdh · 2026-03-23T13:13:21Z

crates/matrix-sdk-crypto/src/gossiping/machine.rs

+                        let encrypted_event_type = content.event_type().to_owned();
+                        let request = ToDeviceRequest::new(
+                            device.user_id(),
+                            device.device_id().to_owned(),
+                            &encrypted_event_type,
+                            content.cast(),
+                        );
+                        let request = OutgoingRequest {
+                            request_id: request.txn_id.clone(),
+                            request: Arc::new(request.into()),
+                        };
+                        self.inner
+                            .outgoing_requests
+                            .write()
+                            .insert(request.request_id.clone(), request);


do the messages and their msgids get logged anywhere, so we can see what is going on?

richvdh · 2026-03-23T13:16:25Z

crates/matrix-sdk-crypto/src/types/events/secret_push.rs

+impl Drop for SecretPushContent {
+    fn drop(&mut self) {
+        self.zeroize()
+    }
+}


you could use derive(ZeroizeOnDrop) for this

richvdh · 2026-03-23T13:17:27Z

crates/matrix-sdk-crypto/CHANGELOG.md

+- Add support for MSC4385.
+  - Add new method `OlmMachine::push_secret_to_verified_devices`.


again, wrong place. Also, needs a PR link.

richvdh · 2026-03-23T13:19:21Z

crates/matrix-sdk-crypto/src/gossiping/machine.rs

+        if sender != self.user_id() {
+            // Ignore if sent from a different user
+            error!(?sender, "Received secret push from a different user");
+            return Ok(());
+        }
+        let Some(device) = self.inner.store.get_device_from_curve_key(sender, *sender_key).await?
+        else {
+            error!(?sender, ?sender_key, "Received secret push from unknown device");
+            return Ok(());
+        };
+        if !device.is_verified() {
+            error!(?sender, device_id = ?device.device_id(), "Received secret push from unverified device");
+            return Ok(());
+        }


I think these should be warnings rather than errors, since they can be caused by other users or devices doing unexpected things, rather than necessarily reflecting an internal error on our side?

uhoreg requested review from a team as code owners February 12, 2026 00:29

uhoreg requested review from poljar and stefanceriu and removed request for a team February 12, 2026 00:29

uhoreg mentioned this pull request Feb 12, 2026

add bindings for secret pushing matrix-org/matrix-sdk-crypto-wasm#295

Draft

richvdh reviewed Feb 25, 2026

View reviewed changes

stefanceriu removed their request for review March 4, 2026 08:36

poljar removed their request for review March 11, 2026 10:39

uhoreg added 2 commits March 19, 2026 13:02

make secrets inbox store just the secret

fce94da

rather than a full `GossippedSecret` struct

add functionality to push secrets to verified devices

feb9c44

uhoreg force-pushed the secret_push branch from f0cfff6 to 14f4f79 Compare March 19, 2026 18:56

handle receiving pushed secrets

51fc07e

uhoreg force-pushed the secret_push branch from 14f4f79 to 51fc07e Compare March 19, 2026 19:07

uhoreg requested a review from richvdh March 19, 2026 19:51

richvdh requested changes Mar 23, 2026

View reviewed changes

		- Add support for MSC4385.
		- Add new method `OlmMachine::push_secret_to_verified_devices`.

Conversation

uhoreg commented Feb 12, 2026

Uh oh!

codecov bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

codspeed-hq bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will not alter performance

Uh oh!

richvdh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

richvdh left a comment

Choose a reason for hiding this comment

Uh oh!

uhoreg commented Mar 19, 2026

Uh oh!

richvdh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

uhoreg Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecov bot commented Feb 12, 2026 •

edited

Loading

codspeed-hq bot commented Feb 12, 2026 •

edited

Loading

uhoreg Mar 23, 2026 •

edited

Loading