How does cargo-auditable construct the information that it includes in the binary?

[mulkieran]

Hi!

Your README makes the following claim:

"""
Know the exact crate versions used to build your Rust executable. Audit binaries for known bugs or security vulnerabilities in production, at scale, with zero bookkeeping.
"""

So, this should include all dependencies used (as opposed to only those statically linked, which would be a subset of those used). An example would be a procedural macro, which only generates code, but is not linked into an executable.

My question is, does this actually include this information, and if so, how does it gather the information?

Also, given the answer to the first question, how probable is it that a particular package that was used would be omitted from the cargo-auditable generated information in the executable?

[bjorn3]

It uses cargo metadata:

cargo-auditable/cargo-auditable/src/collect_audit_data.rs

Line 18 in da85607

fn get_metadata(args: &RustcArgs, target_triple: &str) -> Metadata {

cargo metadata has an issue where it sometimes returns more dependencies than actually get compiled in when you use the v2 resolver (I believe it is hard coded to the v1 resolver), but afaik it will never omit any dependencies.

[Shnatsel]

To add to that: proc macros are build dependencies, which are also recorded.

[mulkieran]

Ok. So this is a statically determined subset of the packages that cargo-vendor would choose to vendor. And at present it is transitively dependent on the v1 resolver which would return more distinct versions of dependencies and then transitive dependencies of those, than does the v2 resolver. Can you clarify, does cargo metadata method call get_metadata return, e.g., proc_macros or does cargo-auditable have to include that separately through some other mechanism?

[Shnatsel]

We currently get information only from cargo metadata, with --filter-platform for the appropriate target platform. Its output includes normal, build and dev dependencies; dev dependencies are then filtered out by our own code.

There are no data sources for package lists other than cargo metadata, and I do not expect that to change.

Note that cargo metadata also needs to know the list of currently enabled features for its output to match the build configuration. cargo auditable gets the list of enabled features by parsing the arguments passed to rustc to make them reliably match the actual build.

[mulkieran]

Thanks! That is most helpful.