We need to create 陆 page brief for BaseApp audit. The goals is to help auditors with pointing areas of BaseApp where they should focus so they can work up a proposal & estimate.
For BaseApp, we certainly want to consider runTx and runMsgs as highest priority, specifically in terms of how things are cached, when they're persisted and all error modes, because DeliverTx and CheckTx essentially just call these two methods.
Question: who is handling Antehandler? Will it be part of the x/auth?
What do you mean by Question: who is handling Antehandler?
For what concerns BaseApp, anteHandler is just a method that the client type that embeds BaseApp can set via SetAnteHandler. BaseApp.anteHandler is called by runTx and only once.
Question: who is handling Antehandler? Will it be part of the
x/auth?
Yeah so the AnteHandler is technically outside the scope of the BaseApp, since it's app-specific. Although I do recommend that the auditors review x/auth as well since it's so integral to the tx and msg execution flow.
We have some flexibility to go outside of BaseApp, however the scope should be very clear for auditors and our informal commitment from a budget allocation perspective is that this will be a BaseApp-centered audit.
We need to be sure that Antehandler is reviewed locally (inside it's package) and globally - as this is used in every runTx (optionally as @alessio pointed out, but I'm not aware about any app which is not using it). So it can't be reviewed in isolation.
So, we need to be sure that this will be properly handled through crypto.com part or our part.
I do recommend that the auditors review x/auth
I agree with that.
optionally as @alessio pointed out, but I'm not aware about any app which is not using it
The point is not whether apps use antehandler - obviously they do. The point is that antehandler as provided by BaseApp is just an interface. Antehandlers are app-specific and require to be treated (and audited) as such.
The SDK comes with a modular mechanism for building antehandlers pipelines, see types.{AnteHandler,AnteDecorator,ChainAnteDecorators}. That is worth looking into. I'll drop some explanations in the brief.
Also worth mentioning this will likely be a time-bound audit per crypto.com's request, so some notion of precedence could be useful.
We need to be sure that Antehandler is reviewed locally (inside it's package) and globally - as this is used in every runTx (optionally as @alessio pointed out, but I'm not aware about any app which is not using it). So it can't be reviewed in isolation.
I don't understand how this is possible? Do you mean BaseApp should be audited assuming the default x/auth AnteHandler is used?
I've extended the brief with an explanation of how antehandler and antehandler decorators work. That seems in scope of this audit
I don't understand how this is possible? Do you mean
BaseAppshould be audited assuming the defaultx/authAnteHandleris used?
I'm saying that AnteHandler must not be audited in isolation.
Correct. The standard one provided by x/auth should be reviewed in conjunction with BaseApp per https://github.com/cosmos/cosmos-sdk/issues/8078#issuecomment-739925947
I suspect this can be closed. I'd defer the decision to close this to @hxrts and @okwme though
Yes, however the brief does link to this issue. So for posterity, I'll note that closure here is in reference to creation of the brief, not completion of the audit.
Most helpful comment
We have some flexibility to go outside of
BaseApp, however the scope should be very clear for auditors and our informal commitment from a budget allocation perspective is that this will be aBaseApp-centered audit.