# Advisory: Debug Symbol Ecosystem Landscape

**Date**: 2026-02-19
**Status**: ARCHIVED (no new gaps)
**Disposition**: Validates existing architecture; no sprint tasks required.

---

## Advisory Content

The modern **debug symbol ecosystem** is quietly coalescing around a few open standards and patterns that matter deeply if you're building debuginfo/symbol retrieval tooling, mirrors, or secure redistribution systems — and the vendor landscape + formats/licensing are more fragmented than you might expect.

`debuginfod` from **elfutils** has emerged as the de-facto HTTP API for build-id → debuginfo/executable/source retrieval, with clients caching aggressively and servers typically exposing endpoints like:

* `GET /buildid/<hash>/debuginfo`
* `GET /buildid/<hash>/executable`
* and related source or section paths
  over simple HTTP/HTTPS, indexed by build IDs embedded in ELF/DWARF objects.

Most Linux distros now offer or federate debuginfod servers (e.g., Fedora, Debian, Ubuntu, openSUSE) that tools like GDB/LLDB, `debuginfod-find` and libdebuginfod can consume by setting `DEBUGINFOD_URLS`.

**BTFHub** fills another niche for kernel toolchains: it's a canonical **Apache-2.0-licensed archive of BPF Type Format (BTF) files** for many published Linux kernels, allowing eBPF runtimes and tools to retrieve BTF when the kernel doesn't embed it.

Symbol server and debug symbol trends across ecosystems are heterogeneous:

* **Microsoft's Public Symbol Server** exposes Windows symbols for automated debugger consumption (e.g., Windbg) via symbol path mechanisms, but its license explicitly restricts **redistribution** outside tooling/contract terms.

* **Mozilla's Firefox Symbol Server** hosts debug symbols (PDB-like or similar) for nightly and release builds and uses upload jobs to populate symbols; integration is similar in concept to MS's servers but with its own workflows and policies.

These vendor servers predate debuginfod and aren't directly redistributable without respecting their respective **license terms / upload policies**.

Under the hood, the **debug formats themselves remain normative**:

* DWARF (v5+ in modern toolchains) is the standard hierarchical debug info format in ELF objects.
* BTF is the compact, kernel-centric type format optimized for eBPF and tooling portability (used by libbpf and CO-RE tooling).

Operational patterns that have emerged:

1. **Live lookup via debuginfod/symbol-server endpoints** with strong **cache-first logic** and pinned build-IDs (`DEBUGINFOD_URLS`, client caching).
2. **Signed artifact bundles** (e.g., DSSE/in-toto) anchored to transparency logs (e.g., Rekor) for **redistributable symbol packs** or marketplace distribution (toolchains outside public servers).
3. **Enterprise mirrors + signed BTF bundles** for air-gapped sync: sync via rsync or OCI-style layers, groom cache, and serve locally to internal debug fleets under your own policies.

Because vendor symbol servers (e.g., Microsoft's) **explicitly limit raw redistribution**, production systems should avoid republishing raw symbols from these endpoints unless you have a contractual agreement — instead rely on **attested metadata or signed bundles** you control.

### References

- [Introducing debuginfod, the elfutils debuginfo server](https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server)
- [elfutils debuginfod services](https://sourceware.org/elfutils/Debuginfod.html)
- [aquasecurity/btfhub](https://github.com/aquasecurity/btfhub)
- [Microsoft Public Symbol Server for Windows Debuggers](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols)
- [Using the Mozilla symbol server](https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/Using_the_Mozilla_symbol_server.html)

---

## Analysis

### Outcome: No new gaps — archive

Every pattern described in this advisory is already implemented or in-progress in Stella Ops:

| Advisory Topic | Stella Ops Coverage | Module(s) |
|---|---|---|
| debuginfod integration | `DebuginfodConnector` — 3-phase pipeline (Fetch→Parse→Map), multi-server fallback, IMA sig framework | `src/BinaryIndex/` |
| DWARF parsing | `DwarfDebugReader`, function boundary detection, confidence tiers | `src/Scanner/` |
| Symbol server / distribution | Multi-tenant REST API, CAS-backed storage, DSSE-signed manifests | `src/Symbols/` |
| OCI symbol packs | `application/vnd.stella.symbols.manifest.v1+json` as referrer artifacts | `src/Symbols/` |
| Signed artifact bundles | DSSE envelopes, Rekor-backed transparency, offline bundle management | `src/Symbols/`, `src/Attestor/` |
| Enterprise mirrors / air-gap | OCI-layer sync, offline kits, RootPack bundles | `src/AirGap/`, `src/Symbols/` |
| Build-ID binding | ELF Build-IDs, PDB GUIDs, GNU build-ids | `src/Symbols/`, `src/BinaryIndex/` |
| BTF / BTFHub | Partial — eBPF micro-witness uses deterministic symbolization tuples; not a primary connector | `src/Signals/` |

### Competitive validation

"Symbolized call-stack proofs" is claimed as a moat differentiator (REACH-005, REACH-006) in `docs/product/moat-strategy-summary.md`. This advisory confirms industry alignment with that positioning.

### Note on BTFHub

BTFHub (Apache-2.0 BTF archive) is not directly integrated as a ground-truth connector. Adding it would be incremental if kernel-level eBPF tooling becomes a customer requirement. Not actionable today.