Digests of reviewed versions, digital signatures

[arnohaase]

Are digests for reviewed artifacts, and reviewers' digitital signatures part of the audit data? I did not see anything like that, but I may have missed this.

If not, how does vet verify that the audit applies to the code being used in a project?

[bholley]

Are digests for reviewed artifacts, and reviewers' digitital signatures part of the audit data?

Digests are only included in the case where the audit corresponds to a git commit rather than a proper release of the crate (as discussed here).

If not, how does vet verify that the audit applies to the code being used in a project?

Cargo-vet primarily operates on releases from crates.io, for which digests are published in the public append-only crates.io registry index. In other words, the index maps (crate, version) to digest, and so by depending on the index, cargo-vet can map that tuple to digest without including the digest inline.

[arnohaase]

Thank you for your reply.

The first-party section of the book says explicitly that "cargo-vet lacks a hash by which to uniquely identify the actual package contents". That may not be a problem so far, but experience with older eco systems (Maven, Node) suggests that enterprises may start hosting their own repos, which may be less secure than crates.io and may diverge from it. The way I read the documentation, vet does not target this kind of scenario. Do I read that correctly?

And I found no mention of digital signatures on audits, the assumption probably being that trust needs to be placed in the source of audit files, rather than ensuring it end-to-end?

I think I understand that cargo-vet prioritizes a low entry barrier, and I'm not suggesting that the trade-offs involved don't make sense, I'm just trying to understand what cargo-vet does and does not do.

[bholley]

The first-party section of the book says explicitly that "cargo-vet lacks a hash by which to uniquely identify the actual package contents".

That sentence is specific to path dependencies (in-repository code) which the user has designated as corresponding to a public crate on crates.io (via the audit-as-crates-io feature). It's not a general statement.

That may not be a problem so far, but experience with older eco systems (Maven, Node) suggests that enterprises may start hosting their own repos,

I assume you mean "hosting their own registries"?

which may be less secure than crates.io and may diverge from it. The way I read the documentation, vet does not target this kind of scenario. Do I read that correctly?

Cargo-vet does not (yet) support alternate registries, though in principle it could. We haven't seen any user interest thus far.

And I found no mention of digital signatures on audits, the assumption probably being that trust needs to be placed in the source of audit files, rather than ensuring it end-to-end?

Correct. Cargo-vet operates at the granularity of organizations/projects rather than individuals. Organizations can (and sometimes do) cryptographically bind audits to authors (by requiring them to sign the relevant git commit) but cargo-vet operates only on the audit file, not any VCS history that may have been involved in creating it.

I think I understand that cargo-vet prioritizes a low entry barrier, and I'm not suggesting that the trade-offs involved don't make sense, I'm just trying to understand what cargo-vet does and does not do.

Low entry barrier is part of it, but there are other reasons, particularly:

• The closest thing to a standard developer identity system is GitHub, and several large participants (Mozilla and Google) do not use GitHub for primary development.
• Cargo-vet uses organizations as the trust unit, because they're much more widely-recognizable than individual developers.

[arnohaase]

Thank you for taking the time and helping me understand cargo vet!

[bholley]

Sure thing. :-)