Is there a good way to visualise rust-audit-info json? (Also additional dependencies may be present) #182
Comments
I think so. rustls-webpki has the cargo feature to depend on ring enabled by default. And boring-rustls-provider doesn't disable it. |
|
Yeah, the format isn't meant to be human-readable. You can convert it to CycloneDX with https://github.com/rust-secure-code/cargo-auditable/tree/master/auditable2cdx or Syft and feed that into any dependency explorer/visualizer that supports CycloneDX, that should give a nicer tree. |
But it is disabled: And i can also manually disable it in my cargo.toml / lock, and it still gets pull in. As in: so ring crate was not fetched, not compiled, yet it is in the audit information. Is rust-audit-info calculated separately, or is it based on compiled crates & linked crates? Cause if there was no rlib / rmeta, and it didn't get linked into the binary how come there is a runtime dep? If i rebuild the binary with tls-ring feature there are rlib / rmeta files for libring. And lots of elf symbols starting with ring_ and lots of output with ring_ in It feels like a false positive metadata in rust-audit-info of a component that is not present in the binary. Which should be mostly harmless, but i was hoping to use it for FIPS cryptography determination, to see if unapproved/not-certified libraries are linked. Looks like I cannot do that. It feels as if rust-audit-info is based on cargo.lock file data; irrespective of which features are enabled. should attempt to create a smaller reproducer? |
|
The audit information may occasionally include too many dependencies due to the limitations of I've been looking into using the |
|
I've looked into this specific dependency before. Because of those metadata bugs and and rust-lang/cargo#10801, I also ended up resorting to checking whether ring is actually built by cargo during the build. |
xnox
changed the title
|
Implemented build tree sure for positive/negative search of .rmeta files, and also elf symbol check for positive/negative symbols with help from rustfilt. This way I can be sure that libring was not built, and no ring symbols are present. I feel confident with these checks. I still dislike the false positive in the rust audit info. Is there anything I can do, at workspace level to override these? Pondering if I should create local works of crates, change their features, use replaces, and recalculate lock. |
|
Building each crate in its own workspace may help, although I don't know if it will really eliminate all the false positives in this case. The way to fix this in I'll discuss with the Cargo team and see if there is a way to either obtain the resolver version from cargo or reimplement the algorithm that determines it outside Cargo. |
without knowing how it works; i was hoping you can encode whatever is needed inside .rmeta files; and then at link stage to have a hook that has access to which .rmeta's are being linked and generate the json at that point for the linked binary. To me that's the only reliable way to pertaining this information throughout the build =) (or .rlib's portion of .rmeta / compiler info inside there) |
|
The format of the crate metadata is unstable and rustc doesn't expose a way to encode arbitrary information in it. |
|
I've talked to a Cargo maintainer, and it seems that it's now feasible to match Cargo's dependency resolution mechanism exactly. I'll see what I can do. I'm going to close this as a duplicate of #66, please follow that issue for updates. |
It is difficult to resolve the dependencies IDs, is there anything that would substitute names for the digits? or at least augument the json with digits?
Is there anything that can generate graph (mermaid or graphviz) from the json?
Also what is the difference between no kind specified, and kind "build"? Are the kind "build" crates linked into the final binary?
I am trying to understand why "ring" crate got into this binary, and if it really is present in the binary and used, or not.
ztunnel.json.txt.gz
Look at the numbers:
Mentally subtract one, as less -N is 1-indexed, and dependencies appear to be 0-indexed
Now try to trace edges
Abriviated:
Does this mean that ztunnel depends on boring-rustls-provider (29) & rustls (239)?
And boring-rustls-provider (29) depends on both rustls (239) and rustls-webpki (243)?
And finally "rustls-webpki" depends on ring (232)?
Did I parse this right?
It would have helped a lot if rust-audit-info could translate this to humans by replacing integer references with names; and also allow to show graph without kind build; or just the kind build.
The text was updated successfully, but these errors were encountered: