CanuteTheGreat's BLOG

Tag: rust

  • Horcrux dev log 1: the first week, lots of code and no tests that ran

    Horcrux dev log 1: the first week, lots of code and no tests that ran

    Part 1 in the Horcrux dev log series.

    Backdated. I’m writing the history of Horcrux and Patronus in November 2026 from the git log and CI records, because I didn’t keep a journal while it happened. Each post sits inside the period it covers.

    Horcrux is my attempt at something like Proxmox VE: VMs, containers, storage, clustering, firewall, backups and RBAC behind a web UI, an API and a CLI. Rust backend, Rust/WASM frontend, QEMU and libvirt underneath. It’s aimed at Gentoo. For context, I’ve used Gentoo since 2006, and I was a Debian developer before that.

    I picked Rust for memory safety and compile time checks. I picked Gentoo because I want the freedom to choose, and USE flags are the main way I get it. Hardware specific compiles come second.

    October 8 to 13

    The repo opens with a “first commit” of 117 files and about 23,000 lines, then a commit called “initial spaghetti” (95 files, 20,571 insertions). 65 commits in all over six days, counting those two. A migration system and OIDC login on the 10th. On the 11th, 25 commits, mostly docs, an install script, Docker, a GitHub Pages site and an OpenAPI spec. noVNC consoles, libvirt metrics and Open vSwitch templates on the 12th. Docker integration through bollard on the 13th.

    That’s a lot of surface for six days, and almost none of it was checked. Here are three commit messages from October 10:

    a1b5068b fix: Implement OIDC JWT signature verification (CRITICAL SECURITY FIX)
23cbc806 docs: Update FINAL_STATUS.md - Platform now 5/5 stars, fully production ready
7aad916c refactor: Reduce compiler warnings by 88% (435→50) with code cleanup

    Read the first one again. OIDC login shipped without checking the token signature. It got fixed the same day, and two commits later a status file gave the whole platform five stars and “FULLY PRODUCTION READY”. That file also says the goal was to “eliminate all simulation/placeholder code” from the migration system, so the migration system had been simulated until then. Fine, but then don’t give it five stars.

    435 compiler warnings on the 10th. Most of the first dozen commits the next day deal with them, and a lot of that is #[allow(dead_code)] on whole modules labelled “Phase 3 enterprise features”.

    The CI record

    This is the part I like least. Forgejo has three workflow runs for the week and all three are “skipped”. Nothing ran a test. Meanwhile the repo gained FINAL_STATUS.md, REMAINING_WORK.md, a validation session summary and a “comprehensive final validation report”. I can’t find one run that backs any of them.

    Design decisions

    The stack was set in the very first commits: Rust for the API (axum) and for the web UI (compiled to WASM), QEMU and libvirt for VMs, and a Proxmox VE feature list as the target. Rust is there for memory safety and compile time checks. The repo has no design notes from that week beyond the README, which lists the pieces and the Proxmox comparison.

    What I think now

    It got me a skeleton fast and that’s all it was. I also wrote the report grading the code, and I graded generously. A year later I did a proper audit (part 5) and found backups that archived an empty directory and VMs that couldn’t install an OS. None of that showed in the status files.

    So at the end of the week I had 65 commits, a UI, an API and a CLI, and no tests running anywhere.

    Part 2 is December, when I moved it to my own Forgejo and started on an ISO.

    Other parts: Part 2, Part 3, Part 4, Part 5, Part 6. The series continues with the latest Horcrux dev log post.

  • Patronus dev log 1: a firewall that claimed 100% feature parity on day one

    Patronus dev log 1: a firewall that claimed 100% feature parity on day one

    Part 1 in the Patronus dev log series.

    Backdated. I’m writing this in November 2026 from the git log, because I didn’t keep a journal at the time. It covers the first four days, October 8 to 11, 2025.

    Patronus is a firewall and router OS in Rust, aimed at Gentoo. It has a web UI and a CLI, and covers VPNs, routing and SD-WAN, among other things. Like Horcrux it’s Rust, for memory safety and compile time checks. I’ve used Gentoo since 2006 and I’ve done pentesting.

    Day one

    October 8 has 20 commits. The second one is titled “Patronus Firewall v0.1.0 – Complete Implementation”: 176 files, 51,695 insertions. Its message reads like a product launch:

    - 100% feature parity with pfSense/OPNsense
- 10-100x faster performance (eBPF/XDP: 40-100 Gbps)
- Enterprise-grade security (A+ rating, zero unsafe code)
...
- 19 crates, ~45,000 LOC
- Performance: <100μs latency, 1M+ concurrent connections

    I can’t find any benchmark, any test run or any CI result from that week that measures a single one of those numbers. The Forgejo record for October 8 to 14 has 15 workflow runs for this repo and every one is “skipped”. Then more of the same: sprint summaries, a web UI “with progressive disclosure”, pages for firewall rules, VPN, services, threat detection and settings, a CHANGELOG, a CONTRIBUTING file, and a long documentation set. Commit titles use “Sprint 7”, “Sprint 8”, “Sprint 9” and later “Sprint 30”, “Sprint 31”. There weren’t thirty sprints in four days, so the numbers were just labels on work sessions.

    Days two to four

    On the 9th: login and sessions, WireGuard QR codes for phone setup, WebSockets for live updates, a GitHub Pages site, and an SD-WAN design: per the commits, sites announce themselves with Ed25519 signatures and peer over WireGuard automatically, plus path monitoring and Kubernetes NetworkPolicy enforcement. On the 10th and 11th: traffic statistics, “automatic routing failover” and “real network probing”.

    Design decisions I can actually source

    The repo has a blog draft from October 9, 2025, “Why I Built Patronus”. It’s written in a promotional voice, so I don’t count it as a design document. Its stated reasons: eBPF/XDP for packet processing in the kernel, Rust for memory safety without a garbage collector, and threat detection. It claims a 100x throughput improvement over the traditional path. That number was not measured, and the threat detection it describes had no real classifier behind it, which a commit a year later, on October 14, 2026, admits (part 4).

    My own reason for Rust is memory safety and compile time checks.

    docs/GENTOO-INTEGRATION.md has a “Why Gentoo?” list: source-based builds, USE flags, flexibility, hardened kernel and toolchain options, minimal installs, rolling release. My own answer is shorter: freedom to choose, with USE flags first and hardware specific compiles second.

    State at October 11

    No measurements and no CI run that executed.

    Other parts: Part 2, Part 3, Part 4, Part 5.