Using crev to validate dependency updates

Problem to solve

In GitLab, merge requests that update or add dependencies are among the most difficult to review. If the code is vendored (e.g. Go), the MR diff is huge and difficult to work with. If the code isn't vendored (e.g. Ruby), then we're dealing with a bunch of arbitrary number changes to a file like Gemfile. None of this tells us what we want to know - is it safe to update / add the dependency?

Target audience

Reviewers, maintainers, security analysts

Further details

Crev (https://github.com/dpc/crev) defines a (newish) standard way to review dependencies. For instance, if working in a Rust project, cargo-crev can be used to get information about the quality of dependencies in the Cargo.toml file that specifies its dependencies. Reviews are signed by authors and web-of-trust characteristics can be used to determine which reviews to accept, and which to discard.

Proposal

It seems to me that frontending crev in GitLab gives us an opportunity to start providing meaningful information about the quality of newly-introduced dependencies. As a follow-up, we could also use the provided information to make it easy to review newly-introduced dependencies and submit those reviews for the author, helping to build up the store of information.

What does success look like, and how can we measure that?

In a year's time, I introduce a new dependency to gitlab in an MR and get a notification like "dhh has reviewed this gem and found its quality to be very low".

Links / references

@bikebilly @jramsay It's to do with MRs, but it's also to do with code security, so I've given it both labels for now. Crev is still very new, but I think it's a promising direction, and having GitLab support it earlier could materially contribute to its overall success. I've not spoken with the authors about this yet.