Ignore build.rs

[anderejd]

Should cargo-geiger ignore build.rs since that code doesn't end up in the target binary?

Summary

Yes, cargo-geiger should ignore build.rs.

[Shnatsel]

TL;DR: yes.

Build scripts have a completely different attack model. They can run arbitrary code at build time - steal your passwords, download malware, you name it. Whether they use unsafe in there or not is irrelevant.

What we should be concerned is build.rs generating code with unsafe that does end up in the build, but that's covered by the "just run the compiler lint" approach described in #102

In the same vein, unsafe code in dev- and build-dependencies should be excluded from the tally.

[tarcieri]

agree with @Shnatsel: I think of cargo-geiger as a static analysis tool, and what build.rs does is anything but static.

[anderejd]

Great, let's make it ignore build.rs!

[anderejd]

In the same vein, unsafe code in dev- and build-dependencies should be excluded from the tally.

Should build and dev dependencies be completely ignored, never scanned, never reported, or only ignored when summing up the final score on the bottom line?

[Shnatsel]

Well, build dependencies have a totally different threat model, so I don't see how looking for unsafe code in them would be useful. It would be misleading, if anything. And dev depdencies ostensibly don't affect the final binary at all.

I'd just exclude them completely, and wait for someone with a use case for scanning them to show up.

[anderejd]

Sounds good to me.

[kornelski]

I am interested in the "completely different attack model" of crates attacking the build machine, because they can inject unsafe code into the executable. For example, nothing stops a sneaky crate from modifying ~/.cargo/registry to inject malware into other crates.

Could you consider an option in cargo-geiger that flags all build-time code execution? build.rs, proc macros.