> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.
I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache?
I personally appreciated having the `find` command:
* It very clearly indicates where to look (my cargo registry cache)
* It very clearly indicates what files to look for (a list of wildcards)
* It's something that I can easily review and then copy/paste into my terminal
* I can very easily adapt it to my particular environment (perhaps into a `fd` invocation if I'm on Windows, or perhaps adapt it to scan all home directories on my system), or feed these file names into some other vulnerability scanner
I believe what's being suggested is that `cargo audit` should be a part of cargo rather than an add on.
You'd obviously already have cargo installed, which means you should be able to run a command against cargo to see if you are currently exposed to any security problems. Even if it's not the current "audit" add on.
Well, but as a system admin, I might not have cargo installed even if my users have it installed in their home directory. So a simple non-Cargo command (like find) has a lot of advantages for me
As someone using bazel at work, the find script was much more amenable to me trying to audit our usage - we don't use cargo, so no cargo cache or cargo audit, but I can still figure out whether a particular package was downloaded.
If you're using a different tool then it falls to that tool to address the same problem. The point is that I shouldn't have to already know that a compromise has occurred and then go looking for it manually. The tooling should automatically start shouting at me very loudly that something happened with one of the packages I'm using.