Textual Internal Audit

[amaury1093]

Textual Internal Audit

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

Note: there is an external audit happening. However, it's useful to also have an internal one, to check things that external auditors might not, such as:

• API naming and godocs
• can the spec be improved (e.g. re human readability)?
• make sure that the spec and implementation both match 1:1 (e.g. there's no hidden implementation detail that's not in the spec)

Scope

• Value Renderers
  • any @AmauryM chore: Audit Textual any, coins, message #15550
  • bytes
  • coin/coins @AmauryM chore: Audit Textual any, coins, message #15550
  • dec
  • duration @AmauryM
  • enum
  • int
  • message @AmauryM chore: Audit Textual any, coins, message #15550
  • repeated @AmauryM
  • string @AmauryM
  • timestamp @AmauryM
  • tx envelope
  • dispatcher @AmauryM chore: Audit Textual any, coins, message #15550
• Encoding
  • CBOR implementation @AmauryM
  • Sign Doc
• Wiring
  • sign mode handler x/auth/tx/textual.go
  • server-side instantiation NewTextualWithBankKeeper
  • client-side instantiation NewTextualWithGRPCConn

Methodology

The following checklist should be run for each item in the Scope. This audit should be performed on commit hash a8dcedd.

• API audit
  • Are public structs, interfaces, methods and types well-named and organized?
  • Is everything well documented (inline godoc)?
• Code correctness
  • Verify correctness upon visual inspection
  • Ensure all state machine code which could be confusing is properly commented
  • Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient
  • 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
  • Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
• Spec
  • Can we improve human readability while maintaining security?
  • Is the spec fully implemented?
  • Are there implementation choices that should be documented in the spec?

[amaury1093]

Here's the wip audit report: https://hackmd.io/@amaurym/BJ2IOrlWn (@facundomedica's also an admin of the doc).

[facundomedica]

Audit concluded, read the finished audit here: https://hackmd.io/G35OvyFES5C3tOnEuej0yw