You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the original goals of this project was and still is to make it simple to use in CI as a pre-build step. cargo-geiger should be able verify that no new unsafe usage or any unsafe usage at all, depending on user configuration, slips into production.
TODO
Improve the cargo API integration
Change the details of the cargo API calls to use the proper cargo flags. Most if not all cargo-flags should be properly interpreted to imitate what a normal cargo build invocation does. If the user wants to test cargo build --release which would likely be the normal case in CI, then the call to cargo-geiger should be cargo-geiger --release. This should allow the cargo build --release call to reuse most of the intermediate build artifacts produced by cargo-geiger. Why is this not already the case? The original idea was to never invoke rustc to avoid the heavy build process, but this turned out to be inadequate since cargo itself only knows of the entry point source code files and leaves the rest for rustc to resolve.
Prototype a "fast forbid mode"
The current assumption in cargo-geiger is that cargo is able to resolve all entry point source code files, which means that we could run the #[forbid(unsafe_code)] scan without doing a single rustc call, which would significantly speed things up, at the cost of disabling the other metrics for this specific mode.
A simple file containing a list of crates (with versons), placed in the application project root, that are trusted to use unsafe code. In other words a list of crates with specific versions that are permitted to not declare #[forbid(unsafe_code)]. This is intended to allow CI automatically discover when a dependency that:
used to be pure safe rust, introduce unsafe code directly or through a dependency.
did previously use unsafe code, publish a new version that is not in the trustlist, awaiting audit and trust list approval.
Create an example CI test project
Create it in this repository or a new one, whatever seems best at that time.
Add some free open source CI system to run it.
The text was updated successfully, but these errors were encountered:
What?
Dogfooding:
https://en.wikipedia.org/wiki/Eating_your_own_dog_food
Continuous Integration:
One of the original goals of this project was and still is to make it simple to use in CI as a pre-build step.
cargo-geiger
should be able verify that no new unsafe usage or any unsafe usage at all, depending on user configuration, slips into production.TODO
Improve the cargo API integration
Change the details of the cargo API calls to use the proper cargo flags. Most if not all cargo-flags should be properly interpreted to imitate what a normal cargo build invocation does. If the user wants to test
cargo build --release
which would likely be the normal case in CI, then the call tocargo-geiger
should becargo-geiger --release
. This should allow thecargo build --release
call to reuse most of the intermediate build artifacts produced bycargo-geiger
. Why is this not already the case? The original idea was to never invokerustc
to avoid the heavy build process, but this turned out to be inadequate since cargo itself only knows of the entry point source code files and leaves the rest forrustc
to resolve.Prototype a "fast forbid mode"
The current assumption in cargo-geiger is that cargo is able to resolve all entry point source code files, which means that we could run the
#[forbid(unsafe_code)]
scan without doing a singlerustc
call, which would significantly speed things up, at the cost of disabling the other metrics for this specific mode.✅ #68
Implement a crate (+ version) trustlist
A simple file containing a list of crates (with versons), placed in the application project root, that are trusted to use unsafe code. In other words a list of crates with specific versions that are permitted to not declare
#[forbid(unsafe_code)]
. This is intended to allow CI automatically discover when a dependency that:Create an example CI test project
The text was updated successfully, but these errors were encountered: