Introducing lightnvr-rs: a Rust build of LightNVR, generated from the C

[matteius]

With #873 merged, every LightNVR release from 0.47.3 on will ship a second build of the backend: lightnvr-rs, a Rust translation of the C code. This post explains what it is, why we did it, and, most importantly, what it does not change.

TL;DR

• Nothing changes for you if you run the C build. C is still the source of truth and still produces the native builds, .deb packages and the ghcr.io/opensensor/lightnvr image, exactly as before.
• Nothing changes for contributors. You write C. You don't need Rust installed, and you never edit rust/ by hand.
• What's new: CI translates the C into Rust on every pull request, builds it, and runs the smoke and API contract tests against it. Starting with 0.47.3, releases publish the result next to the C artifacts:
  • ghcr.io/opensensor/lightnvr-rs:<version>
  • lightnvr-rs_<version>_sid_amd64.deb

Why we're doing this

More and more organizations, especially schools, public agencies and other institutions, have procurement or security policies that favor or require software written in memory-safe languages, following guidance from CISA, the NSA and others. For many of them, "it's written in C" ends the conversation before LightNVR's actual track record (sanitizer builds, static analysis, CodeQL, API contract tests) even comes up.

A hand rewrite in Rust would take years and would split the project: two codebases, two sets of bugs, and features landing in one but not the other. We didn't want that. Instead, the C stays the spec and the Rust is derived from it mechanically, so the two builds can never drift apart.

How it works

• tools/rust-transpile/generate.py runs C2Rust over the same sources and build flags as the native build, at a pinned C2Rust revision and Rust toolchain (tools/rust-transpile/toolchain.json).
• The generated crate lives in rust/. rust/MANIFEST.json records, for every module, the hash of the C file it came from, so you can trace any Rust function back to its C origin.
• The few mechanical fixes the generated code needs to compile live in one auditable place, tools/rust-transpile/repairs.py, not scattered as hand edits.
• On every PR, the lightnvr-rs workflow regenerates rust/, commits the result for you, builds it, and runs the smoke tests and the API contract suite against the Rust binary. lightnvr-rs-guard rejects any PR whose rust/ doesn't match a fresh generation or that contains human edits to rust/.
• The Rust image uses the same runtime as the C image (web UI, go2rtc, database migrations, entrypoint). Only the backend binary differs.

What lightnvr-rs is, and what it isn't (yet)

We want to be precise here, because overclaiming would help nobody.

It is a faithful, reproducible Rust translation of the whole LightNVR backend, built with the Rust toolchain, tested against the same API contracts as the C build, and traceable line by line to its C source.

It is not yet idiomatic, safe Rust. C2Rust produces C-shaped Rust: most of it is inside unsafe blocks, and it links the same native libraries as the C build (FFmpeg, SQLite, libuv, curl, mbedTLS and so on). Today the memory-safety properties of lightnvr-rs are essentially the same as the C build's. Passing our tests also doesn't prove full behavioral parity with C; it means the contract suite passes.

What it gives us is a foundation: a Rust codebase that already builds, ships and passes tests, and from which unsafe can be removed step by step, with the C spec and the contract tests as the safety net. It also gives organizations that need a Rust artifact for policy reasons a supported, release-tracked one today.

FAQ

Is C going away?
No. C is the spec. Features, fixes and reviews all happen in C.

Which build should I run?
If you have no specific requirement, keep running the C build. It's the reference and has the longest track record. Choose lightnvr-rs if your organization needs a Rust-built artifact, or if you want to help us test it.

Do I need Rust to contribute?
No. CI handles translation and building. If your C change happens to break the Rust build, the PR check will tell you, and a mechanical fix usually belongs in repairs.py.

What platforms does lightnvr-rs support?
For now, amd64 (Debian sid .deb and the container image). More architectures will follow.

Can I send a PR that edits rust/ directly?
No. CI rejects it. Change the C, or the generator and repairs.

Where do I report a problem?
Open an issue and say which build you're running (lightnvr or lightnvr-rs) and its version. A bug that appears only in lightnvr-rs is especially useful to us.

Questions and feedback are welcome below, and we'd especially like to hear from anyone evaluating LightNVR under a memory-safety policy.