Analyzing `--release` profile of binaries
repi opened this issue · comments
Is there an option to analyze the builds from --release mode instead of the ordinary debug mode? typically they are the same but can and are differences between them and generally is the --release binaries that are used for users, and that have highest security importance.
Could see it being of interest to analyze multiple profiles, just to be safe, and to cover potential custom Cargo profiles also.
Example
One concrete "issue" I ran into that motivated this was with @nical's lyon_tessellation crate that in debug-only reads an environment variable and as such uses env capability/API:
I could ofc all the env capability to the this crate in our config, but as this is only for debug builds and not our --release builds I would like to avoid that.
There is a flag --profile that does this. It's currently hidden from the help, since it's not quite 100%. In particular, analysing optimised code can make figuring out which crate some code came from harder. That said, it's getting relatively close, at least for the couple of crates I've analysed.
But I guess what you're after is not necessarily analysing optimised code, but analysing code with debug_assertions turned off.
You could probably add something like this to your Cargo.toml:
[profile.cackle-release]
inherits = "release"
opt-level = 0I'd be interested to hear how you go with this.
thanks, will try it out!
and yes makes sense that would be harder to analyze a fully optimized binary, and the main (and only, I think) way to detect release(-like) profile in Rust is the debug_assertions check so having a profile with it disabled as well as optimizations disabled feels like it should work
But I guess what you're after is not necessarily analysing optimised code, but analysing code with debug_assertions turned off.
You could probably add something like this to your
Cargo.toml:[profile.cackle-release] inherits = "release" opt-level = 0
can confirm this works, lyon_tessellation with this is no longer detected to use env as that path is not compiled due to the cfg statements in it
so that's good!
is there a way to streamline and not having to specify --profile=cackle-release for every invocation, like having which profile to use by default in cackle.toml? like
[common]
default-profile = "cackle-release"
or maybe make it possible to override the default cackle profile it uses in one's Cargo.toml, now it defined with env vars on command-line which overrides if one defines it oneself in Cargo.toml
I added common.profile as an option in the config file.
thanks that works well!