For final build artifacts (executables, as well as some other formats in the case of embedded, wasm, FFI, …), agreed! (For intermediate build artifacts (libs and stuff cached under target/ in a workspace), I expect nothing special should be needed: a new compiler of any kind shouldn’t match/use old artifacts and cargo will rebuild dependencies).
As a tangential illustration, the cargo-update crate contains a cargo addon command install-update that deals with updating binaries installed with cargo install when their corresponding source crates change. There’s also an option to force-rebuild everything, which I’ll sometimes do for example when the compiler has changed, “just because”. It would be great if ‘was built with vulnerable components’ could also trigger such a rebuild.
This isn’t so much a feature request for that crate specifically, as for the surrounding infrastructure that publishes the data to enable such decisions by tooling generally.
There’s also maybe some scope opportunity/discussion to settle: an expansion of “vulnerable components” to include ecosystem crate tags (using cargo audit data), and maybe some slightly broader set of important compiler+std updates that probably also include some really significant features, performance changes, soundness-but-not-security fixes.
As a smallest possible starting point: is there a crate today to analyse build artifacts and extract the relevant metadata about compiler and dependency versions, or to abstract over many possible platform formats to do so? Is there some machine-independent metadata blob that rustc can embed (in a platform-specific way), so that the format layer only has to know how to find the blob?
