nobilis's own code is memory-safe Rust: two unsafe blocks in the whole daemon, both in main.rs, both sound and documented - mallopt(M_ARENA_MAX, 4) and malloc_trim(0), plain libc calls that take integers and touch no Rust memory. (The one mem::forget keeps the lock file's handle open for the process's life; a leak by intent, not a safety question.)
Nothing keeps it that way. Two things would:
#![deny(unsafe_code)] at the crate root, with #[allow(unsafe_code)] on the two functions that need it - so a new unsafe block fails the build until somebody writes it down on purpose, with a SAFETY comment.
An advisory check in the release workflow - cargo audit (or cargo deny check advisories) against the lockfile, failing on a vulnerability and warning on unmaintained crates. This audit found the issues filed alongside this one by querying OSV by hand; a machine should do that on every push.
nobilis's own code is memory-safe Rust: two `unsafe` blocks in the whole daemon, both in `main.rs`, both sound and documented - `mallopt(M_ARENA_MAX, 4)` and `malloc_trim(0)`, plain libc calls that take integers and touch no Rust memory. (The one `mem::forget` keeps the lock file's handle open for the process's life; a leak by intent, not a safety question.)
Nothing keeps it that way. Two things would:
1. **`#![deny(unsafe_code)]`** at the crate root, with `#[allow(unsafe_code)]` on the two functions that need it - so a new `unsafe` block fails the build until somebody writes it down on purpose, with a SAFETY comment.
2. **An advisory check in the release workflow** - `cargo audit` (or `cargo deny check advisories`) against the lockfile, failing on a vulnerability and warning on unmaintained crates. This audit found the issues filed alongside this one by querying OSV by hand; a machine should do that on every push.
Salastil
added this to the v1.0 milestone 2026-10-02 19:03:42 -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.
nobilis's own code is memory-safe Rust: two
unsafeblocks in the whole daemon, both inmain.rs, both sound and documented -mallopt(M_ARENA_MAX, 4)andmalloc_trim(0), plain libc calls that take integers and touch no Rust memory. (The onemem::forgetkeeps the lock file's handle open for the process's life; a leak by intent, not a safety question.)Nothing keeps it that way. Two things would:
#![deny(unsafe_code)]at the crate root, with#[allow(unsafe_code)]on the two functions that need it - so a newunsafeblock fails the build until somebody writes it down on purpose, with a SAFETY comment.cargo audit(orcargo deny check advisories) against the lockfile, failing on a vulnerability and warning on unmaintained crates. This audit found the issues filed alongside this one by querying OSV by hand; a machine should do that on every push.