Attribute-macro-based auditing annotations

[sam0x17]

The Polkadot/Substrate ecosystem is looking for a solution that will allow us to annotate pallets (rust modules) and possibly other portions of our codebase with an attribute macro with syntax similar to #[audited(E0C5E21EB7AD91AA)] where the contents of audited() are a hash code of the syn-parsed AST nodes that make up the pallet (minus some superfluous nodes, such as doc/comment nodes).

Right now the substrate ecosystem maintains an auditing team that audits new pallets and incremental changes to existing pallets, however these auditing results are not stored anywhere in the repo and are simply managed at the PR level.

The idea here would be to make this audited() attribute macro fail if the hash code changes, which ideally would only happen if a portion of the rust module that the attribute is applied to has been modified, which would trigger a re-audit.

Then we would provide syntax for runtime developers to assert at compile-time that all pallets used in their runtime have been audited, which would be a huge win security-wise for our ecosystem, since accidentally using unaudited pallets is a recurring issue for runtime developers.

So it would look something like this within our system:

#[pallet]
#[audited(E0C5E21EB7AD91AA)]
pub mod pallet {
  ...
}

Because we control how the attribute macro generates its hash code, we could do things like ignore certain node types that we deem harmless (comments, docs, etc), so this would give us even finer grained control if desirable.

Anyway, I wanted to reach out here and see how viable the rust secure code working group thinks this idea might be.

Right now pallets are heavily restricted (via macro generation) to be entirely defined in a single module that follows a particular format and sits in a single file.

Conveniently, all the proc_macro2 / syn node types have hash implementations and our preliminary tests indicate that these hash codes are stable. The same module placed in different projects/files seems to result in the same hash code, minor changes result in a new hash code, etc.

The original forum thread discussing this can be found here and has a bit more context, if desirable: https://forum.polkadot.network/t/rfc-trustless-in-code-auditing-annotations/988

What do you think of this sort of approach? Has anyone tried anything like this before? In other words, what is the viability of using hash codes of ASTs in this way?