cargo: only prefetch/report crates the build can actually use?

[wseaton]

Hey folks, wanted to float a feature idea before I open a PR.

We build a Rust project in Konflux (opendatahub-io/modelexpress) with --no-default-features --features openssl for FIPS. The binaries are clean, no ring or rustls anywhere in them. But the SBOM still says the image contains rustls, ring, hyper-rustls, google-cloud-auth, etc., because Hermeto reports everything in Cargo.lock, and Cargo.lock has every optional dep whether or not a feature turns it on. The consequence of this is CVE noise (potentially needing to file VEX justification for crates we are not using) and an onlooker might look at the SBOM and see a package included like ring and think the image is not actually FIPS compliant.

There's not much we can do about it on our side. rustls is an optional dep of reqwest, so it lands in basically any lockfile with reqwest in it.

The idea: let the cargo input say what's actually being built (similar in concept to https://github.com/coreos/cargo-vendor-filterer/), something like

{
  "type": "cargo",
  "path": ".",
  "packages": [
    {"name": "modelexpress-server", "no_default_features": true, "features": ["openssl"]}
  ],
  "platforms": ["x86_64-unknown-linux-gnu", "aarch64-unknown-linux-gnu"]
}

and Hermeto only prefetches/reports what's reachable from that. Everything else gets stubbed so Cargo.lock still resolves but can't be compiled. Nice side effect: it fails closed. If the input says less than the Containerfile actually builds, the build breaks instead of the SBOM quietly being wrong.

I hacked up a local prototype and it takes us from 552 reported crates to 338, with the TLS stuff gone. Both binaries still build offline against it, and building with the default rustls features fails like it should.

The thing I'm not sure about: this would use cargo tree --locked to figure out what's reachable. It never picks or changes versions (the lockfile is still the source of truth, we just take a subset), and it doesn't run build scripts. But it is doing feature/target resolution, and I know "Hermeto never resolves dependencies itself" is a core principle. Does narrowing the locked graph like this fit, or would you rather this get solved somewhere else, like in the SBOM tooling downstream?

A couple other things to ponder:

• Naming for the fields, and whether platforms could default to the build target.
• Proc-macros and build-script deps get compiled but not linked. Maybe report those separately, like pip's requirements_build_files?
• All cargo inputs (and pip's cargo runs for sdists) share deps/cargo, so stubbing would need to account for every input, not just one.

If this sounds reasonable I'm happy to open an issue and a draft PR.

[cgwalters]

(similar in concept to https://github.com/coreos/cargo-vendor-filterer/),

(Background: I created and maintain that project)

Everything else gets stubbed so Cargo.lock still resolves but can't be compiled. Nice side effect: it fails closed. If the input says less than the Containerfile actually builds, the build breaks instead of the SBOM quietly being wrong.

Ideally we'd share code for this; at the current time vendor-filterer is focused on platform filtering, not features, but it seems tractable to change.

[cgwalters]

coreos/cargo-vendor-filterer#144 implements a feature to filter by features.