From a memory-safety audit of nobilis on 2 October 2026: its own code has two unsafe blocks (both sound libc calls in main.rs), so what follows is about the code it depends on. Advisories were checked against the OSV/RustSec database for every crate in Cargo.lock, and each one traced to whether it is actually compiled in.
Two advisories arrive through the matrix-sdk crates, and both are fixed by moving them to 0.19 (with the ruma versions it pins - which is why this is an upgrade, not a cargo update):
imbl-sized-chunks 0.1.3 - RUSTSEC-2026-0292, double free / use-after-free in Chunk and InlineArray removal methods when an element's Drop panics. A genuine memory-safety bug, reached through imbl <- eyeball-im <- matrix-sdk-base / matrix-sdk-common. Hard to trigger - an element's destructor has to panic mid-removal - but it is undefined behaviour in the process that holds the Matrix crypto store. Fixed in 0.2.0.
bitmaps 3.2.1, through the same imbl - RUSTSEC-2025-0167, Bitmap::try_from(&[u8]) can construct invalid values (unsound), and RUSTSEC-2026-0247, unmaintained.
matrix-sdk-crypto 0.18.0 - RUSTSEC-2026-0318, sending custom to-device messages may panic. nobilis enables exactly that feature (experimental-send-custom-to-device, used for Element Call's media keys). Fixed in 0.19.0.
Done when the matrix-sdk crates are on 0.19, cargo test passes, and a Matrix login, an encrypted room and an Element Call still work.
From a memory-safety audit of nobilis on 2 October 2026: its own code has two `unsafe` blocks (both sound libc calls in `main.rs`), so what follows is about the code it depends on. Advisories were checked against the OSV/RustSec database for every crate in `Cargo.lock`, and each one traced to whether it is actually compiled in.
Two advisories arrive through the matrix-sdk crates, and both are fixed by moving them to 0.19 (with the ruma versions it pins - which is why this is an upgrade, not a `cargo update`):
- **imbl-sized-chunks 0.1.3** - RUSTSEC-2026-0292, *double free / use-after-free in `Chunk` and `InlineArray` removal methods when an element's `Drop` panics*. A genuine memory-safety bug, reached through `imbl` <- `eyeball-im` <- `matrix-sdk-base` / `matrix-sdk-common`. Hard to trigger - an element's destructor has to panic mid-removal - but it is undefined behaviour in the process that holds the Matrix crypto store. Fixed in 0.2.0.
- **bitmaps 3.2.1**, through the same `imbl` - RUSTSEC-2025-0167, `Bitmap::try_from(&[u8])` can construct invalid values (unsound), and RUSTSEC-2026-0247, unmaintained.
- **matrix-sdk-crypto 0.18.0** - RUSTSEC-2026-0318, *sending custom to-device messages may panic*. nobilis enables exactly that feature (`experimental-send-custom-to-device`, used for Element Call's media keys). Fixed in 0.19.0.
Done when the matrix-sdk crates are on 0.19, `cargo test` passes, and a Matrix login, an encrypted room and an Element Call still work.
Salastil
added this to the v1.0 milestone 2026-10-02 19:03:38 -04:00
Salastil
added the bugCVE labels 2026-10-02 19:03:38 -04:00
The Matrix crates are now on 0.19.1, and all four advisories are cleared: RUSTSEC-2026-0292, -2025-0167, -2026-0247 and -2026-0318. OSV finds nothing new.
The upgrade turned out to involve more than the Matrix crates. matrix-sdk-sqlite 0.19 needs rusqlite 0.40, and only one bundled SQLite can be linked, so rusqlite went 0.37 → 0.40. That in turn needed arti 0.47, the first version whose tor-dirmgr accepts rusqlite 0.40. arti 0.47 brings saturating-time 0.5.0, which still has the bug that hangs Tor on Windows, so it has been re-vendored with the same fix.
Verified:
cargo test: 829 pass. Clippy shows no new warnings.
A copy of the live @salastil:poa.st crypto store opens under 0.19 with the same identity keys and all 32 room keys. 0.19 migrates its schema (17 → 19), and 0.18 can still open the migrated store, so rolling back wouldn't strand it.
Tor bootstraps and reaches an onion service over TLS on Linux and on the Windows VM (cross-built).
Still to check by hand, before this is closed: a Matrix login, an encrypted room and an Element Call.
The Matrix crates are now on 0.19.1, and all four advisories are cleared: RUSTSEC-2026-0292, -2025-0167, -2026-0247 and -2026-0318. OSV finds nothing new.
The upgrade turned out to involve more than the Matrix crates. matrix-sdk-sqlite 0.19 needs **rusqlite 0.40**, and only one bundled SQLite can be linked, so rusqlite went 0.37 → 0.40. That in turn needed **arti 0.47**, the first version whose tor-dirmgr accepts rusqlite 0.40. arti 0.47 brings saturating-time 0.5.0, which still has the bug that hangs Tor on Windows, so it has been re-vendored with the same fix.
Verified:
- `cargo test`: 829 pass. Clippy shows no new warnings.
- A copy of the live @salastil:poa.st crypto store opens under 0.19 with the same identity keys and all 32 room keys. 0.19 migrates its schema (17 → 19), and 0.18 can still open the migrated store, so rolling back wouldn't strand it.
- Tor bootstraps and reaches an onion service over TLS on Linux and on the Windows VM (cross-built).
Still to check by hand, before this is closed: a Matrix login, an encrypted room and an Element Call.
- nobilis: https://git.salastil.com/Salastil/nobilis/commit/c34b751
- moho: https://git.salastil.com/Salastil/moho/commit/9ce478a
Salastil
removed this from the v1.0 milestone 2026-10-03 21:30:49 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
From a memory-safety audit of nobilis on 2 October 2026: its own code has two
unsafeblocks (both sound libc calls inmain.rs), so what follows is about the code it depends on. Advisories were checked against the OSV/RustSec database for every crate inCargo.lock, and each one traced to whether it is actually compiled in.Two advisories arrive through the matrix-sdk crates, and both are fixed by moving them to 0.19 (with the ruma versions it pins - which is why this is an upgrade, not a
cargo update):ChunkandInlineArrayremoval methods when an element'sDroppanics. A genuine memory-safety bug, reached throughimbl<-eyeball-im<-matrix-sdk-base/matrix-sdk-common. Hard to trigger - an element's destructor has to panic mid-removal - but it is undefined behaviour in the process that holds the Matrix crypto store. Fixed in 0.2.0.imbl- RUSTSEC-2025-0167,Bitmap::try_from(&[u8])can construct invalid values (unsound), and RUSTSEC-2026-0247, unmaintained.experimental-send-custom-to-device, used for Element Call's media keys). Fixed in 0.19.0.Done when the matrix-sdk crates are on 0.19,
cargo testpasses, and a Matrix login, an encrypted room and an Element Call still work.The Matrix crates are now on 0.19.1, and all four advisories are cleared: RUSTSEC-2026-0292, -2025-0167, -2026-0247 and -2026-0318. OSV finds nothing new.
The upgrade turned out to involve more than the Matrix crates. matrix-sdk-sqlite 0.19 needs rusqlite 0.40, and only one bundled SQLite can be linked, so rusqlite went 0.37 → 0.40. That in turn needed arti 0.47, the first version whose tor-dirmgr accepts rusqlite 0.40. arti 0.47 brings saturating-time 0.5.0, which still has the bug that hangs Tor on Windows, so it has been re-vendored with the same fix.
Verified:
cargo test: 829 pass. Clippy shows no new warnings.Still to check by hand, before this is closed: a Matrix login, an encrypted room and an Element Call.