gef + rizin: the scriptable half of the reverse-engineering loadout - #547

The other half of the reverse-engineering loadout: the scriptable disassembler, and the thing that makes gdb worth sitting next to a decompiler. Follows #544 (gdb, merged) and pairs with #545 (ghidra).

rizin 0.9.1 — the use_sys_* decisions ARE the package

Ghidra answers "what does this function do"; rizin answers "run that over 400 binaries and diff the results" — the shape this distro's own tooling works in.

All seventeen use_sys_* options default to disabled, so out of the box rizin statically links its own zlib, zstd, xz, lz4, pcre2, openssl and tree-sitter. Those copies are invisible to pkgscan: a CVE in any of them would never appear against this package. For a distro whose premise is supply-chain vuln tracking, seven silently-vendored libraries is the wrong default.

All seven now link from the system — verified in the built tree:

libz.so.1   libzstd   liblzma.so   liblz4   libpcre2-8/16/32
libcrypto.so.3   libtree-sitter.so.0.26

Deliberately left vendored, and named rather than left to be discovered: capstone (rizin defaults to use_capstone_version=next — the unreleased capstone 6, so a "system" capstone would be a different disassembler than it was tested against), plus libzip / magic / zydis / xxhash / libmspack / softfloat / blake2 / blake3, which we do not package.

--wrap-mode=nodownload is what makes it hermetic: the official rizin-src tarball vendors its subprojects, and the flag makes meson fail rather than reach for the network if one is ever missing.

Licence recorded as GPL-3.0-or-later, not the LGPL-3.0-only of the core — the linked binary aggregates a 16-licence REUSE union including GPL-3.0 and GPL-2.0 files, so the permissive core alone would understate it.

gef 2026.01 — a launcher, not a dotfile edit

MIT, and genuinely a single file: gef.py is 433 KB of Python whose every import is stdlib.

Upstream's install instructions append a source line to ~/.gdbinit, which would make this package mutate the user's home directory and silently change the behaviour of every unrelated gdb invocation on the machine. Instead gef is a separate entry point — gdb with gef loaded — and gdb stays exactly what it was.

gef.py asserts GDB_MIN_VERSION (10,0) and PYTHON_MIN_VERSION (3,10) at import time; ours are 17.2 and 3.14. The gdb package from #544 is built --with-python precisely so this works, and that flag is pinned by a test over there rather than trusted.

Tests, targeting the failure each package actually has

Both mutation-tested — breaking any assertion makes minimal check fail.

rizin system_libs — meson probes for each system library and falls back to the vendored subproject when one is missing, printing a note and carrying on to a successful build. You would get a working rizin with seven invisible bundled libraries: exactly what the flags exist to prevent, and nothing else would notice. The test asserts all seven appear in the librz_* DT_NEEDED.

Two bugs in my own first version of that test, both caught by running it: it used readelf without declaring binutils (failed loudly — correct), and it asserted against /usr/bin/rizin, which is a thin frontend carrying none of these. The linkage lives in librz_*.so.

gef loads_into_gdb — there is no compile step, so the only way this package breaks is gdb failing to import it, and that is quiet: gdb prints the traceback to stderr, carries on to a normal prompt, and exits 0. So nothing asserts on the exit code. One test checks gef help registers as a command (only true if the file imported to its last line); the other checks no Traceback appears, since a partial import leaves gef present with most commands missing.

Verified

minimal package --rebuild --no-fetch {gef,rizin}   exit 0
minimal check --packages {gef,rizin}               14/14 each
rizin                                              ELF aarch64, 8 rz-* tools
reproducibility                                    byte-identical across rebuilds
pkgmgr check                                       both resolve up_to_date

Why the reveng loadout is not in this PR yet

It was, and I removed it — because it does not build. stacks/reveng/stack.ncl references ghidra, which lands in #545, and the whole repo then fails to evaluate:

Error: package 'ghidra' does not exist

That is not theoretical: it broke every build on my working branch, including gef and rizin, which were fine. Worth knowing that minimal check --stacks does not catch it — I tested packages valid against a deliberately nonexistent package name and it still reported Pass. Only a build catches a bad stack reference.

So the loadout commit is ready and will be pushed to this same branch the moment #545 merges, keeping it one PR for the final bunch. Its content is unchanged from what I verified locally alongside ghidra: 6/6 stack checks, and a build_cmd that exercises all four anchors rather than merely listing them — because each fails silently in its own way.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added the GEF package with a GDB launcher and Python debugging support.
  • Added Rizin 0.9.1 for binary analysis and reverse engineering.
  • Added an opt-in reverse-engineering stack with Ghidra, Rizin, GDB, GEF, and supporting tools.
• Quality
  • Added installation, version, integration, executable-analysis, and runtime-library validation.
  • Builds use verified upstream sources and reproducible settings.