x/authz Module Readiness Checklist

[clevinson]

x/authz Module Readiness Checklist

This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release.

Reports

• docs and audit x/authz docs and spec audit #9035
• completeness, API and state machine audit x/authz completeness audit #9037

Prior to beta tag

• API audit (at least 1 person) (@robert-zaremba , @anilcse)
  • spec audit: check if the spec is complete.
  • Are Msg and Query methods and types well-named and organized?
  • Is everything well documented (inline godoc as well as /spec/ folder in module directory)
  • check the proto definition - make sure everything is in accordance to ADR-30
    • @robert-zaremba
    • @anilcse
    • @cyberbono3
• Completeness audit, fully implemented with tests (at least 1 person) (@robert-zaremba )
  • Genesis import and export of all state
  • Query services
  • CLI methods
  • All necessary migration scripts are present (if this is an upgrade of existing module)
  • Assess maintainability and risks of future migrations

Release Candidate Checklist

The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on master, or preferably on a alpha or beta release tag that includes the module.

The module should not be included in any Release Candidate tag until it has passed this checklist.

• State machine audit (at least 2 people) (@robert-zaremba @cyberbono3 @anilcse)
  • Read through MsgServer code and verify correctness upon visual inspection
  • Ensure all state machine code which could be confusing is properly commented
  • Make sure state machine logic matches Msg method documentation
  • Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
  • Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to:
    • algorithmic complexity and places this could be exploited (ex. nested for loops)
    • charging gas complex computation (ex. for loops)
    • Storage is safe (we don't pollute the state).
  • Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed

Published Release Checklist

After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary):

• Code snippets update after merging x/authz: audit updates #9042.
• Testnet / devnet testing (2-3 people) (@robert-zaremba @cyberbono3 @anilcse )
  • All Msg methods have been tested especially in light of any potential threats identified
  • Genesis import and export has been tested
• Nice to have (and needed in some cases if threats could be high): Official 3rd party audit

[robert-zaremba]

I've added few more entries to the checklist.
The state machines checks we will do in pairs:
Robert: keeper (Wed 20:00 CEST), client (Tue 17:00 CEST)
Anil: client, simulation
Andrei: keeper, simulation

[blushi]

@robert-zaremba more generally, should we update the module readiness checklist template to account for those new entries and have it consistent across all audited modules?

[robert-zaremba]

@blushi - yes, that would be good. The checks are

• Storage is safe (we don't pollute the state).
• make sure everything is in accordance to the respective ADR (in case of authz it's ADR-30)

[blushi]

@blushi - yes, that would be good. The checks are

• Storage is safe (we don't pollute the state).
• make sure everything is in accordance to the respective ADR (in case of authz it's ADR-30)

We have also added simulation as part of the Module Readiness Checklist for feegrant as it was not already explicitly stated in the checklist.
Maybe let's discuss and align on those new checks before updating the Module Readiness Checklist template but afaic, those make sense to me.

cc/ @clevinson