Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Dogfooding CI example #63

Open
Tracked by #241
anderejd opened this issue Jul 17, 2019 · 1 comment
Open
Tracked by #241

Add a Dogfooding CI example #63

anderejd opened this issue Jul 17, 2019 · 1 comment
Labels
doc enhancement New feature or request
Milestone

Comments

@anderejd
Copy link
Contributor

anderejd commented Jul 17, 2019

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 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.

#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:

  • 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.
@anderejd anderejd added the enhancement New feature or request label Jul 17, 2019
@pinkforest
Copy link
Collaborator

I saw someone was already using cargo-geiger on CI
https://github.com/maidsafe/bls_signature_aggregator/blob/master/.github/workflows/pr.yml#63-93

De-coupling will be done in next major

I've added some thinking on sanity checking unsafe #213

And we can enforce as unsafe exclusionary DNS RBL function via WG-42 rust-secure-code/wg#42

Also I am looking to get input from user-runs into geiger.rs for which we could add flag --contribute or just use the WG-43 rust-secure-code/wg#43

As for this project as we get those things implemented we can use some reference crates to run on against.

For now I could just add one example -

You also probably know I am working on geiger.rs service :)
rust-secure-code/wg#19 (comment)

@pinkforest pinkforest added the doc label Jan 6, 2022
@pinkforest pinkforest added this to the M-0.12.0 milestone Jan 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants