I was discussing the possibility of tracking audit trails using an attribute, as outlined here, with a friend earlier today. Our conversation centered around what it means for code to be auditable, and I raised my concern that an attribute is the wrong place to track audit trail, because the trail needs to be invalidated if the audited block changes.
After pondering for some time, he mused that it’s ok for the inspected code to change, so long as the emitted code doesn’t change. (This line of reasoning isn’t entirely accurate, but it’s close enough for the time being.) This led me to wonder whether, conceptually, it would be feasible to export the MIR for the audited block, and if so, in broad strokes, how might that be done?
The idea-at-large is to track audit trail largely in source control (say, as git notes). An auditing tool could scan for #[safe] blocks, generate their MIR, and attach it in the note as audit data. If the audited code is changed, the tool would generate new MIR and compare it to the stored MIR. If the MIR changed, it would flag the block to be re-audited.
Now that I’ve written it out, the idea seems ludicrous, but I don’t know enough about Rust to truly discount it. Could someone point out where I might start learning about it?