Skip to content

feat: auto-generate authority pattern list from std's MIR #53

@bordumb

Description

@bordumb

Problem

The authority pattern list in classify_authority() (capsec-deep) and build_registry() (cargo-capsec) is manually maintained. When Rust adds new I/O functions to std, we don't detect them with proper category labels (FS/NET/ENV/PROC) until someone manually adds the pattern. The FFI catch-all (is_foreign_item()) still detects them, but only as generic FFI findings without meaningful categorization.

Proposal

Use --deep on the standard library itself to auto-generate the authority registry. The MIR driver can already trace every std function that transitively calls a foreign function. The output is effectively the definitive list of all authority-bearing functions in std.

Approach

  1. Run capsec-driver on std (via RUSTC_WRAPPER on a dummy crate that depends on std)
  2. For each finding, extract the call chain: std::fs::read → ... → libc::read
  3. Categorize by the top-level std module (std::fs::* → FS, std::net::* → NET, etc.)
  4. Output a generated authority_registry.rs or JSON file that replaces the hand-maintained build_registry() and classify_authority() tables
  5. Run this as a CI job pinned to each Rust release — diff the output against the current registry and open a PR if new functions appear

Benefits

  • Zero manual maintenance — new std I/O functions get proper category labels automatically
  • Catches functions we've missed (e.g., std::fs::File::sync_all, std::fs::hard_link were missing from the syntactic registry)
  • Single source of truth derived from the compiler itself
  • Could also run on popular crates (tokio, reqwest, hyper) to auto-generate patterns for third-party I/O

Open questions

  • Should the generated list replace build_registry() entirely, or supplement it?
  • How to handle std functions that call FFI but aren't really "authority" (e.g., allocator internals)?
  • What Rust edition/version to pin the generation to?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions