We are looking for a solution on how to communicate which crates were audited and which were not. For example the broker pallet is not audited, but how to communicate this?
Without knowing the options I would have proposed the versioning scheme which is pretty straight forward and explicit, people installing a crate can immediately tell from the version but relying on the same trusted entity to publish crates with the right tag can be tricky. cargo crev looks promising and could scale well, it’s nice that is even Ianguage independent in case we see ourselves needing audited non Rust code.
Yea, (ab)using the versioning scheme has the advantage of clear visibility, but it does not play well with the standard semver rules since it is not treated as a proper release.
I am not sure familiar with all the other options, but once looking into the problem we have, and the possible solutions, this seemed to me to be the best bang for our buck. It will solve the issue, and is pretty simple.
To be clear, I am looking at this mainly from the point of view of the fellowship and how it’s going to upgrade its dependencies whilst knowing everything is still audited.
Small nit, I would do it the other way around: Parity, ORML, and others should freely publish their pallets, and noteworthy audit teams in the ecosystem should re-publish them with -audited.
I’d be extremely interested, and would love to see, Parity adopt crev/vec over the polkadot-sdk repo and publish not only crev/vet statements for their tags, yet have any external researchers they work with do so (not to mention host statements from ecosystem projects who spend the time to review pallets/changes).
From my understanding of security, Parity does work with an external group to do review of at least some of the repo (I believe the group in question is funded through Polkadot governance), yet I don’t believe their comments are currently public. Having them publish crev/vet statements may be a decent alternative to commentary accumulation/publication.
Publishing multiple tags sounds like we’re asking for not only ecosystem fragmentation (sorry, you used frame-support-1.3.0-audited yet we use frame-support-1.3.0 and now our traits are incompatible) yet also like an increase in supply chain security as one now needs to additionally guarantee 1.3.0-audited matches 1.3.0.
EDIT: Edited to include both crev and vet. I also would like to note I believe the bytecode alliance has adopted vet…
cargo-crev is meant to spot security vulnerabilities or unsoundness.
This is a very different use case than what auditors audit in Substrate. It is not the right tool.
crev wants to build a web of trust of code reviews, with the objective of spotting security vulnerabilities or unsoundness.
Every single piece of information in their README points towards this objective.
Would it for example be appropriate for a pallet crate to get red flagged by crev because its weights are too low? No. Would it be appropriate for a pallet to get red flagged because it requires transactions that are larger than the block size limit? No.
Thanks for bringing up this topic. The Parity AppSec team has been working on a proposal for a while, and it’s published here. It would be great to have your attention and feedback.