DEV Community: Christo

Reading a Rust crate's capabilities out of its compiled symbols

Christo — Sun, 19 Jul 2026 13:05:51 +0000

Cargo tells you once_cell 1.19.0 → 1.20.2. It doesn't tell you whether the new
version started opening a socket. A dependency bump is a trust decision, and the
lockfile diff gives you almost nothing to make it with.

I kept chewing on this after xz. Not the specific attack so much as its shape: the
change that mattered was invisible at the level anyone actually reviews. Nobody
reads the full diff of every transitive dep on every patch bump. So I wanted a
cheaper question answered automatically on the PR: did this bump change what the
crate can do?

You can get further than I expected just by reading what the compiler emits.

v0 symbols are legible

Rust's v0 symbol mangling demangles back to real paths. Build a crate, look at
the rlib:

RUSTFLAGS="-C symbol-mangling-version=v0" cargo build --release
nm target/release/deps/libnetcap-*.rlib \
  | awk '{print $NF}' | grep '^_R' | rustfilt | sort -u

For a crate that opens a socket and spawns a process, some of what falls out:

<std::process::Command>::spawn
<std::sys::net::connection::socket::TcpStream>::connect::inner
<str as std::net::socket_addr::ToSocketAddrs>::to_socket_addrs

My first cut used nm --defined-only, and it found nothing. Took me longer than
I'd like to admit to see why. The capability you care about isn't in the crate's
own functions. It's in the calls it makes out to std, and those are the
undefined symbols in the object files. --defined-only throws away the whole
signal. Once you keep the undefined refs, a crate that reaches for TcpStream
carries an undefined symbol that says so.

Two nice properties fall out of v0 specifically. Demangling drops the per-crate
disambiguator hash, so the same symbol is byte-identical across two versions and
you can just comm -13 the old and new sets. And forcing
-C symbol-mangling-version=v0 means you don't care what the toolchain default is;
the audit reproduces anywhere.

So the core is boring in a good way: for each crate whose version moved in
Cargo.lock, build old and new, diff the demangled symbols, and look at what got
added.

The build.rs blind spot

Then I hit the thing that actually keeps me up, and it's the xz-shaped one. A build
script compiles to a separate binary that Cargo runs at build time. None of that
lands in the crate's rlib. A dependency can add a build.rs that decodes a blob
and drops it in ~/.cargo/bin, and the symbol diff stays perfectly quiet.

// build.rs — runs on your machine, at compile time
fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    let _ = std::process::Command::new("sh")
        .arg("-c").arg(payload())   // symbol analysis never sees this
        .status();
}

The only way to catch it is to read the source, not the artifact. One Rust detail
made that easier than I feared: Cargo extracts a crate into
~/.cargo/registry/src/.../<crate>-<version>/ during resolution, before it
compiles anything. So you can diff a new or changed build.rs, catch a flip to
proc-macro = true, or a fresh links = "…", even for proc-macro-only or bin-only
crates that never build as a lib. Those are exactly the crates the symbol lane
can't touch.

Where it breaks: generics

I don't want to oversell it, because it has a real ceiling and the ceiling is
monomorphization. A generic function only produces a symbol once it's
instantiated. If a crate does this and never calls it with a concrete type itself:

pub fn send<A: ToSocketAddrs>(addr: A) -> io::Result<TcpStream> {
    TcpStream::connect(addr)   // monomorphized in the *caller's* crate, not here
}

then TcpStream::connect shows up in your rlib, not the dependency's. Capability
reached purely through uninstantiated generics is invisible to this. It's a triage
signal — "the surface changed, go look" — not a sandbox and definitely not a proof.
I'd rather say that plainly than pretend otherwise.

Making it something you'd leave on

A scanner that re-flags every bump gets muted within a week, so the part I put the
most thought into is a sign-off ledger. You approve a (crate, version) once, and
after that it only re-alarms on the unreviewed delta. That's what lets you set
fail-on: high and block merges without drowning in noise. The one rule I was
careful about: a sign-off suppresses only the capability lanes. A newly-published
RustSec advisory or a changed crates.io publisher is never hidden by an old
approval, because those are new facts, not the thing you reviewed.

It comes out as one comment per PR:

🟠 HIGH — smallvec has a known security advisory (RUSTSEC-2021-0003)

If you want to poke at it

It's a composite GitHub Action, MIT, no server, runs entirely in your CI. There's
a live demo PR where it catches a real advisory:
https://github.com/Booyaka101/rust-symbol-audit-demo/pull/1, and the repo is
https://github.com/Booyaka101/rust-symbol-audit.

The part I'm least sure about is the false-positive ergonomics — the allow-list and
ledger design — so if you have opinions there, that's the feedback I actually want.

Disclosure: I built this with heavy help from an AI coding assistant (Claude), and
the first draft of this post came out of that too. I've reworked it and I stand
behind every claim here — the design decisions and the opinions are mine. Flagging
it because that's the honest thing to do.

I fire 50 research prompts before bed and read the answers with coffee — free, on Gemini's background tier

Christo — Sun, 19 Jul 2026 10:34:18 +0000

Something slipped into the Gemini API that I don't think enough people clocked: you can run a prompt in the background. You send it, get an interaction ID back in under a second, and the model keeps working server-side while you close your laptop. No held-open connection, no keeping a tab alive.

And on the free tier — gemini-3.1-flash-lite, no billing account, no card — it costs nothing.

That combination is quietly great for one specific thing: research you don't need answered right now. "Summarize this week in AI." "Compare the 2026 EU AI Act timeline against the UK's." "Is anyone actually regretting moving off Postgres?" Questions where you'd happily wait a few minutes, if waiting meant you didn't have to sit there babysitting a terminal.

The problem is the background API hands you the hard half. You get an ID back and now it's yours to manage: remember which prompt it belonged to, poll it, and — the sharp edge — the free tier throws the result away after 24 hours if nothing collects it. Lose the ID or forget to check, and the work is just gone.

So I built the boring client half and called it gemcatch.

npx gemcatch research "compare the 2026 EU AI Act timeline against the UK approach"
# Task 8f3a1c04 submitted. Run: gemcatch get 8f3a1c04 when ready.

# ...close the laptop, come back whenever...
npx gemcatch get 8f3a1c04

It drops every interaction ID into a local SQLite file right next to the prompt that made it, so you never lose the thread. The moment a task finishes, the answer is cached on disk — gemcatch get reads it straight from there, no network, even after the 24-hour server-side expiry.

The part I actually use: batch

One prompt at a time is fine. The reason gemcatch earned a permanent spot in my shell is the batch command. I keep a plain text file of questions and fire the whole thing at once:

$ cat questions.txt
what changed in the EU AI Act in the last month
state of React Server Components adoption in production
is anyone regretting moving off Postgres to a managed KV

$ gemcatch batch questions.txt
Batch batch-7f3a1c: submitted 3 task(s).

$ gemcatch daemon --exit-when-idle                  # poll until they're all collected
$ gemcatch export --tag batch-7f3a1c > answers.md   # every answer, one markdown file

I run that before bed. By morning answers.md is waiting — every prompt and its answer in a single file, ready to read with coffee. And when I want the takeaways instead of the raw pile, gemcatch digest --tag batch-7f3a1c runs them back through the model once and hands me one synthesized summary. It's the closest thing I've got to a research intern who works the night shift for free.

The daemon exists for exactly one reason

That 24-hour expiry is the whole gotcha. Caching a result forever is easy; noticing it landed is the hard part. gemcatch daemon just polls whatever's in flight on a loop and writes each result to SQLite the instant it completes — so nothing gets dropped because you forgot to check back. Kill it, reboot, pull the power; everything it already collected is on disk, and it picks up where it left off.

It's deliberately boring

No dashboard, no account, no telemetry. It's a small pile of Node, a SQLite file, and a handful of commands — research, batch, get, list, watch, daemon, export, digest. Every outbound call is rate-limited and retried so a wide batch stays inside the free tier's limits instead of blowing straight through them. MIT.

npx gemcatch research "your question"

Repo: github.com/Booyaka101/gemcatch

If "ask now, read later, pay nothing" fits how you actually work, I'd love to know what you'd point it at — and what would make the batch flow better. Scheduled/recurring runs are the thing I'm eyeing next.

I stopped trusting "Bun vs Node" blog posts and asked X what devs actually say this week

Christo — Sun, 19 Jul 2026 08:31:26 +0000

The top Google hit for "bun vs node" on my screen was written in early 2024. It benchmarks a Bun that's shipped a dozen releases since. That's how most of us pick tools: reading a snapshot of an argument that already moved on.

The argument that's actually current — the one with real production war stories — is happening on X this week. It's just not indexed anywhere you'd think to look.

So one weekend I built a CLI that asks it directly. It hands your question to Grok 4.5's live X search and makes every claim cite a real post, with a recency tag on each. It's called GrokScope, and you can watch it work in about five seconds — no API key, no signup:

npx grokscope demo

What it found on Bun vs Node (and the bit I didn't expect)

I ran grokscope ask "bun vs node in 2026". The thing that stuck with me: the "Bun is going to kill Node" energy is basically gone. That framing feels like 2023. What's landing now is more skeptical and a lot more specific.

The optimist case is still real, and people are putting numbers on it:

"Moving from Node to Bun was a game changer for me, it cut process usage across all my services by over 20%."
— @bartdominiak

But the pushback has gotten sharper than the usual benchmark flexing:

"Bun has faster http methods? An AI agent can create a .node addon to out perf Bun trivially. No need to switch runtimes."
— @jdalton, who knows these internals better than most of us

And some of the folklore is cracking — one re-benchmark had Deno beating Bun on raw throughput (133k vs 122k req/s), which is not the story anyone was telling twelve months ago.

Where it nets out, and this matches my gut after reading through it: it's not a war anymore. Reach for Bun on greenfield projects, CLIs, scripts, and edge/serverless, where the speed and the batteries-included DX actually pay off and you don't mind the bleeding edge. Stay on Node when boring reliability, native addons, or a large existing codebase are the real constraint. Plenty of teams just run both. Bun's Zig-to-Rust rewrite reads less like a flex and more like it trying to grow up.

The part I like: none of that is me editorializing. It's ~30 days of people who ship this stuff, and I can click through to every source and disagree if I want to.

How it actually works

One call to xAI's Responses API with Grok 4.5's x_search tool switched on. Grok runs the searches, reasons over the posts, and returns text with inline citations; GrokScope renders those as numbered clickable links and decodes each post's date straight from its snowflake ID. No scraping, no X API keys.

grokscope ask "is anyone actually using RSC in prod?"
grokscope compare drizzle prisma
grokscope trending --topics "rust,typescript,go"

There's --json for CI and --md if you want to drop a report into a doc — I generated the pull-quotes above with it.

Responses are also cached locally now, so an identical repeat query — or re-rendering the same result as --json instead of --md — costs nothing, and grokscope history pages back through past runs offline. --fresh forces a live refetch when you want the newest posts.

The honest part

Live queries are bring-your-own xAI key, roughly $0.15–0.30 each the first time (the search pulls dozens of posts into context; it prints the exact cost after every run, so nothing sneaks up on you) — repeats come free from the local cache. The demo is free forever because it just replays a recorded run. It's a weekend side project — MIT, and definitely still has rough edges.

Repo's here: github.com/Booyaka101/grokscope

If you run it, point it at an argument you actually care about and tell me whether the verdict matches your gut. The cases where it's wrong are the ones I most want to hear about.