The curated registry
Installable libraries written in Capa, fetched by name with capa add. These are separate from the standard library, which is built into the language and needs no install. This registry is small and curated: every package below is currently first-party, maintained by the same author as the compiler.
What lives here
The standard library is the set of built-in types, functions and capabilities available in any program with no imports. The registry is the opposite end: external libraries, each in its own git repository, that a project pulls in explicitly. You add one with
$ capa add capa_httpwhich resolves the short name through the registry index, writes a [dependencies.capa_http] block into your capa.toml, and runs the install. Browse the index from the command line with capa search (no term lists everything).
Eight packages
Name, description and latest version are taken verbatim from the registry index. The package name links to its source repository.
| Package | Latest | Install | Description |
|---|---|---|---|
| capa_cli | v0.1.2 | capa add capa_cli | Command-line argument parsing: flags, positionals, subcommands. |
| capa_csv | v0.1.1 | capa add capa_csv | RFC 4180 CSV parser, header view, and writer in pure Capa; zero capabilities. |
| capa_datetime | v0.1.2 | capa add capa_datetime | Date and time values plus formatting; pure, no Clock capability required to format. |
| capa_hash | v0.1.2 | capa add capa_hash | SHA-256, SHA-224 and HMAC-SHA256 in pure Capa; zero capabilities, plus constant-time tag/MAC comparison. |
| capa_http | v0.1.3 | capa add capa_http | HTTP client over the Net capability; urllib-backed request and response handling. |
| capa_log | v0.1.2 | capa add capa_log | Structured logging with levels and formatters over the Stdio capability. |
| capa_sbom | v0.1.0 | capa add capa_sbom | SBOM parsing for CycloneDX and SPDX JSON with capa:* capability queries; zero capabilities. |
| capa_test | v0.1.1 | capa add capa_test | A tiny assertion library for the capa test runner; Stdio-only, no other capabilities. |
How a name is resolved and verified
The registry index does two jobs: it maps a short name to a git URL, and it pins the GPG key that the package's release tags are signed with. Both are protected.
- The index is GPG-signed. capa add <name> fetches index.json and its detached signature index.json.asc, and verifies the exact index bytes against a root-key fingerprint that ships baked into the toolchain, out of band from the index. Verification is fail-closed: an index that is missing its signature, carries a signature that does not verify, or is signed under the wrong key is refused before any entry is trusted. The only opt-out, CAPA_REGISTRY_ALLOW_UNSIGNED=1, applies solely to an index that carries no signature at all (air-gapped or self-hosted mirrors); it never rescues a signature that is present but invalid.
- The git tag is signature-verified on install. Resolving the name also yields the package's verify_key. The install flow then checks that the pinned git tag is signed by that key, so a compromised account that moves a tag to an attacker commit is caught.
- The resolved SHA is locked. The install records the exact commit in capa.lock, so a later retag of the same version is detected.
capa add <name> defaults the pin to the index's latest tag. The fully explicit form skips the index and names everything itself, which is how you add a package that is not in the registry:
$ capa add capa_http --git https://github.com/nelsonduarte/capa_http \
--tag v0.1.3 --verify-key 6C1D222D491FB88031E041A536CFB426101AA24BFor the full flow, the signed-index design, and the per-package layers, see the capa-registry repository.