[chore]: import audits to cargo vet

[MCJOHN974]

Description

I did some googling and found that cargo vet do not automatically do any auditing. Instead, on cargo vet init it marks all dependencies as "exempted". To shrink size of "exempted" set and move crates to "audited" status there are basically two ways:

• Do audit by ourselves
• Import audits

In this PR I import audits provided by some big parties like Google, Mozilla, Bytecode Alliance, etc. (Actually I just copied imports used in cargo vet github repo. This change moves around 100 dependencies from "exempted" to "audited" status.

However, there is still 600 exempted dependencies. We can add some more audit imports, and shrink this size, but I don't believe we can push it down to zero. And I don't think we need to do this, security is never about "build 100% secure code". It always about "let's add some more 9s to our 99.9999% secure code".

Changes

Adds audit imports to cargo vet and updates cargo vet lockfile.

Testing Information

No testing needed, once CI is green it's fine.

Checklist:

• I have performed a self-review of my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[cylewitruk]

@MCJOHN974 I actually spoke with @fabergat about this last night saying that I think we should do this to help reduce the diffs, so I'm for it. But let's get the others' opinions as well -- @djordon @matteojug

[matteojug]

I'm okay with adding trusted audit sources, I'm just not sure if embark and isrg qualifies as such.

[MCJOHN974]

I'm okay with adding trusted audit sources, I'm just not sure if embark and isrg qualifies as such.

@matteojug I just copied list of trusted sources from config.toml in cargo vet repo: https://github.com/mozilla/cargo-vet/blob/main/supply-chain/config.toml

From my opinion while working in this direction we should first try to move as much deps as possible from "exempted" to "audited" status and then try to switch from less trusted audit to more trusted.

[matteojug]

For my opinion working on this direction we should first try to move as much deps as possible from "exempted" to "audited" status and then try to switch from less trusted audit to more trusted.

Yeah good point, better to have someone saying they audited them than just add exceptions.
Approving, but let's wait to hear also from @djordon . Also, you should probably rebase this after the recent #1271.

[cylewitruk]

For my opinion working on this direction we should first try to move as much deps as possible from "exempted" to "audited" status and then try to switch from less trusted audit to more trusted.

Yeah good point, better to have someone saying they audited them than just add exceptions. Approving, but let's wait to hear also from @djordon . Also, you should probably rebase this after the recent #1271.

Yeah I agree with this logic as well -- exemptions give us nothing.

There is the small thing that if it is trusted then it's not going to show up as a diff to give us the opportunity to audit ourselves. But tbh I think that without the trusted imports, the chances of us choosing audit vs. exempt become more slim due to the sheer volume of diffs.

[djordon]

Yeah these changes make sense to me.

The main question I have is what our policy should be for importing an organizations audits. It appears quite consequential, since their mistakes imply a false confidence of our supply chain. Let's chat offline about this and figure out how we want to handle these things.

Some proposed rules:

• Three engineers must agree on importing an organizations audits.
• Imports of a highly trusted organization are trusted.
• Consensus must be reached on designation of a highly trusted organizations.

Let's all chat about this first before merging.