Enforce ProofSpecs in 23-Commitment #6374

AdityaSripal · 2020-06-09T01:43:57Z

Description

Simple way to make 23-commitment use ics23-proofs by still requiring that we use merkle.Proof but enforce that each Op in the proof is as expected by the ibc client.

Taken from: #6344 (comment)

Supersedes #6344

closes: #6321

TODO:

fix tests

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
Code follows the module structure standards.
Wrote unit and integration tests
Updated relevant documentation (docs/) or specification (x/<module>/spec/)
Added relevant godoc comments.
Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
Re-reviewed Files changed in the Github PR explorer

codecov · 2020-06-09T01:47:53Z

Codecov Report

Merging #6374 into master will decrease coverage by 0.06%.
The diff coverage is 44.17%.

@@            Coverage Diff             @@
##           master    #6374      +/-   ##
==========================================
- Coverage   55.71%   55.65%   -0.07%     
==========================================
  Files         465      465              
  Lines       27512    27651     +139     
==========================================
+ Hits        15329    15389      +60     
- Misses      11097    11163      +66     
- Partials     1086     1099      +13

cwgoes

Hmm, don't we want to enforce the full ICS-23 spec (e.g. https://github.com/confio/ics23/blob/master/proofs.proto#L155, including max depth, min depth, etc.)?

If we aim to do that after / separately I suppose this is fine as an intermediate step. This doesn't really constrain what the proof actually contains though.

fedekunze

Looks good 👍 Pending validation comments and test fixes. Thanks @AdityaSripal 🙂

x/ibc/07-tendermint/types/client_state.go

x/ibc/23-commitment/types/merkle.go

x/ibc/23-commitment/types/merkle_test.go

x/ibc/07-tendermint/types/msgs.go

ethanfrey · 2020-06-09T11:37:03Z

Hmm, don't we want to enforce the full ICS-23 spec (e.g. https://github.com/confio/ics23/blob/master/proofs.proto#L155, including max depth, min depth, etc.)?

@cwgoes When decoding proof ops, there is a mapping from the string type to the ics23 spec to be enforced: https://github.com/cosmos/cosmos-sdk/blob/master/store/types/proof.go#L48-L60

This is not extensible yet but simply enforcing the string types for ProofOps, and limiting them all to ics23:* will guarantee the relevant spec is checked: https://github.com/cosmos/cosmos-sdk/blob/master/store/types/proof.go#L145

This definitely could be more extensible and configured elsewhere, but I proposed @AdityaSripal pull this logic out as it will provide correctness. And there is a larger discussion that needs to be had within the team if you want to rip out merkle.ProofOp everywhere for *ics23.CommitmentProof. Until now, the changes have been relatively non-invasive.

My main point is that whatever proof format you use on the ibc packets should be the same proof format you return for abci.Query. If these are different, you are putting a lot more work on the client to keep them in sync, which is much more fragile than testing compatibility in the same codebase

cwgoes · 2020-06-09T12:46:56Z

@cwgoes When decoding proof ops, there is a mapping from the string type to the ics23 spec to be enforced: https://github.com/cosmos/cosmos-sdk/blob/master/store/types/proof.go#L48-L60

This is not extensible yet but simply enforcing the string types for ProofOps, and limiting them all to ics23:* will guarantee the relevant spec is checked: https://github.com/cosmos/cosmos-sdk/blob/master/store/types/proof.go#L145

I see, thanks. That seems reasonable for now.

My main point is that whatever proof format you use on the ibc packets should be the same proof format you return for abci.Query. If these are different, you are putting a lot more work on the client to keep them in sync, which is much more fragile than testing compatibility in the same codebase

Yes, I agree with this.

…into aditya/ibc-commitment

fedekunze

ACK. A few suggestions

x/ibc/07-tendermint/client/cli/tx.go

x/ibc/07-tendermint/types/msgs.go

fedekunze · 2020-06-10T15:53:27Z

x/ibc/07-tendermint/types/client_state.go

+ if err := clientState.Validate(); err != nil {
+ return ClientState{}, err
 }


not required anymore as the check is on the MsgCreateClient validation 👍

Suggested change

if err := clientState.Validate(); err != nil {

return ClientState{}, err

}

Feel free to remove the Initialize function and replace it with just the ClientState constructor

…-commitment

…into aditya/ibc-commitment

cwgoes

The code looks fine, but I'm wondering if we want to allow dynamic ics23.ProofSpec choices when creating a client?

cwgoes · 2020-06-10T20:02:46Z

x/ibc/07-tendermint/client/rest/rest.go

@@ -34,6 +34,7 @@ type CreateClientReq struct {
 TrustingPeriod time.Duration `json:"trusting_period" yaml:"trusting_period"`
 UnbondingPeriod time.Duration `json:"unbonding_period" yaml:"unbonding_period"`
 MaxClockDrift time.Duration `json:"max_clock_drift" yaml:"max_clock_drift"`
+ ProofSpecs []string `json:"proof_specs" yaml:"proof_specs"`


Do we want there to be a way for the client creator to provide the full ics23.ProofSpec?

If we don't have that, then we're limited to whatever specs the SDK has hard-coded "by name".

Hmm.. for now this is not that useful. Since we're still using merkle.Proof and ProofRuntime to verify proofs, we cannot actually verify a proof that isn't registered and hard-coded into the proofruntime anyway.

Think this is something to revisit once we pull out ProofRuntime from ics23 verification

Ahh but I suppose we can change the interfaces now, so we don't have to change them again

Hmm after thinking about it, realized there isn't a simple way to do this without completely pulling out merkle.ProofRuntime from the `23-commitment package.

I can do this if there's consensus that this is preferable, but it does involve more work since I have to manually verify the proof with passed in specs, rather than just calling into ProofRuntime. Not too hard tho

I think this is probably worthwhile, since it will allow SDK chains to support new ProofSpecs without manual upgrades

Ok, so now 23-commitment no longer uses ProofRuntime. Instead we use the ics23 Verify functions directly with the ProofSpecs passed in from the client.

Now, ibc can verify Commitment proofs even if the chain does not have them hardcoded into its proof runtime

Dismissing approval since many changes happened since

fedekunze

ACK, pending a few additional test cases. I recommend you to download the Octolinker browser extension to see line coverage on PRs.

fedekunze · 2020-06-12T07:33:43Z

x/ibc/07-tendermint/client/cli/tx.go

+ case "simple":
+ specs = []*ics23.ProofSpec{ics23.TendermintSpec}
+ default:
+ return fmt.Errorf("proof Spec: %s not supported", spc)


Suggested change

return fmt.Errorf("proof Spec: %s not supported", spc)

return fmt.Errorf("proof spec %s isn't supported", spc)

fedekunze · 2020-06-12T07:34:34Z

x/ibc/07-tendermint/types/client_state.go

@@ -143,9 +140,31 @@ func (cs ClientState) Validate() error {
 if cs.MaxClockDrift == 0 {
 return sdkerrors.Wrap(ErrInvalidMaxClockDrift, "max clock drift cannot be zero")
 }
+ if cs.TrustingPeriod >= cs.UnbondingPeriod {


missing test case

fedekunze · 2020-06-12T07:34:39Z

x/ibc/07-tendermint/types/client_state.go

+ }
+ // Validate ProofSpecs
+ if cs.ProofSpecs == nil {
+ return sdkerrors.Wrap(ErrInvalidProofSpecs, "proof specs cannot be nil for tm client")


missing test case

fedekunze · 2020-06-12T07:34:43Z

x/ibc/07-tendermint/types/client_state.go

+ }
+ for _, spec := range cs.ProofSpecs {
+ if spec == nil {
+ return sdkerrors.Wrap(ErrInvalidProofSpecs, "proof spec cannot be nil")


missing test case

fedekunze · 2020-06-12T07:35:12Z

x/ibc/07-tendermint/types/msgs.go

@@ -95,6 +99,21 @@ func (msg MsgCreateClient) ValidateBasic() error {
 if err := msg.Header.ValidateBasic(msg.Header.ChainID); err != nil {
 return sdkerrors.Wrapf(ErrInvalidHeader, "header failed validatebasic with its own chain-id: %v", err)
 }
+ if msg.TrustingPeriod >= msg.UnbondingPeriod {


missing test case

fedekunze · 2020-06-12T07:35:19Z

x/ibc/07-tendermint/types/msgs.go

+ }
+ // Validate ProofSpecs
+ if msg.ProofSpecs == nil {
+ return sdkerrors.Wrap(ErrInvalidProofSpecs, "proof specs cannot be nil")


missing test case

cwgoes

utACK

Agreed with @fedekunze comments, also would like a quick look by @ethanfrey if he has time

cwgoes · 2020-06-12T10:44:19Z

x/ibc/07-tendermint/client/cli/tx.go

@@ -88,8 +96,20 @@ func GetCmdCreateClient(cdc *codec.Codec) *cobra.Command {
 return err
 }

+ spc := viper.GetString(flagProofSpecs)
+
+ // Currently supports SDK chain or simple kvstore tendermint chain


Can we support reading a spec from JSON or something?

This can happen later though

cwgoes · 2020-06-12T10:57:06Z

... hmm I don't think we wanted to merge this automatically?

fedekunze · 2020-06-12T11:23:32Z

It merges it with 2+ approvals. @AdityaSripal can you add the tests in a separate PR 🙏

Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>

AdityaSripal added 2 commits June 8, 2020 18:28

enforce spec ordering

3d2795c

modify clients to pass in specs to verify functions

a716e20

AdityaSripal requested review from aaronc, alessio, alexanderbez, clevinson, fedekunze and jgimeno as code owners June 9, 2020 01:43

AdityaSripal added the x/ibc label Jun 9, 2020

AdityaSripal requested a review from cwgoes June 9, 2020 01:44

AdityaSripal mentioned this pull request Jun 9, 2020

Make 23-Commitment use ICS23 proofs #6344

Closed

8 tasks

AdityaSripal added the WIP label Jun 9, 2020

start fixing tests

3a5bc6a

cwgoes reviewed Jun 9, 2020

View reviewed changes

fedekunze suggested changes Jun 9, 2020

View reviewed changes

Apply suggestions from code review

1723648

AdityaSripal added 5 commits June 9, 2020 12:45

Merge branch 'aditya/ibc-commitment' of github.com:cosmos/cosmos-sdk …

e0d574d

…into aditya/ibc-commitment

enforce spec length and proof length match

74dd904

fix all tests

e2f3537

add argument to constructor:

57e0a84

Merge branch 'master' into aditya/ibc-commitment

5a9782d

AdityaSripal added R4R and removed WIP labels Jun 9, 2020

AdityaSripal requested review from fedekunze and cwgoes June 9, 2020 21:28

AdityaSripal added 2 commits June 9, 2020 18:03

fixed msg client and tests

6d759cf

appease linter

8e8bfd8

AdityaSripal requested a review from fedekunze June 10, 2020 15:41

fedekunze previously approved these changes Jun 10, 2020

View reviewed changes

Apply suggestions from code review

10c978a

fedekunze added the A:automerge Automatically merge PR once all prerequisites pass. label Jun 10, 2020

AdityaSripal added 4 commits June 10, 2020 13:35

Merge branch 'master' of github.com:cosmos/cosmos-sdk into aditya/ibc…

3e5b687

…-commitment

more robust proof spec checks

f170cf9

Merge branch 'aditya/ibc-commitment' of github.com:cosmos/cosmos-sdk …

f414ad8

…into aditya/ibc-commitment

add CHANGELOG entries

236ab96

cwgoes reviewed Jun 10, 2020

View reviewed changes

fedekunze and others added 5 commits June 11, 2020 13:20

Merge branch 'master' into aditya/ibc-commitment

92e8315

do not hardcode proofspecs in 23-commitment

f441fb1

fix client modules

3731d8a

fix tests

3241a2d

fix merge

f6749b5

AdityaSripal requested review from fedekunze and cwgoes June 11, 2020 23:27

appease linter

0737e09

fedekunze approved these changes Jun 12, 2020

View reviewed changes

cwgoes approved these changes Jun 12, 2020

View reviewed changes

mergify bot merged commit d82c2e6 into master Jun 12, 2020

mergify bot deleted the aditya/ibc-commitment branch June 12, 2020 10:45

AdityaSripal added a commit that referenced this pull request Jun 12, 2020

address review from pr #6374

912c4ad

This was referenced Jun 12, 2020

Review followup of #6374 #6430

Merged

Allow ProofSpec to be passed as JSON in 07-tendermint cli #6431

Closed

mergify bot pushed a commit that referenced this pull request Jun 13, 2020

address review from pr #6374 (#6430)

e07c1e2

Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>

AdityaSripal mentioned this pull request Jun 15, 2020

WIP: Fix ICS23-Proofs #6178

Closed

cwgoes mentioned this pull request Jun 29, 2020

Potential attack vector with Merkle Commitments in ICS-23 #5440

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enforce ProofSpecs in 23-Commitment #6374

Enforce ProofSpecs in 23-Commitment #6374

AdityaSripal commented Jun 9, 2020 •

edited

Loading

codecov bot commented Jun 9, 2020 •

edited

Loading

cwgoes left a comment

fedekunze left a comment

ethanfrey commented Jun 9, 2020

cwgoes commented Jun 9, 2020

fedekunze left a comment

fedekunze Jun 10, 2020

fedekunze Jun 10, 2020

cwgoes left a comment

cwgoes Jun 10, 2020

AdityaSripal Jun 10, 2020

AdityaSripal Jun 10, 2020

AdityaSripal Jun 10, 2020 •

edited

Loading

cwgoes Jun 11, 2020

AdityaSripal Jun 11, 2020

fedekunze left a comment

fedekunze Jun 12, 2020

fedekunze Jun 12, 2020

fedekunze Jun 12, 2020

fedekunze Jun 12, 2020

fedekunze Jun 12, 2020

fedekunze Jun 12, 2020

cwgoes left a comment

cwgoes Jun 12, 2020

cwgoes Jun 12, 2020

cwgoes commented Jun 12, 2020

fedekunze commented Jun 12, 2020

	if err := clientState.Validate(); err != nil {
	return ClientState{}, err
	}

	return fmt.Errorf("proof Spec: %s not supported", spc)
	return fmt.Errorf("proof spec %s isn't supported", spc)

Enforce ProofSpecs in 23-Commitment #6374

Enforce ProofSpecs in 23-Commitment #6374

Conversation

AdityaSripal commented Jun 9, 2020 • edited Loading

Description

codecov bot commented Jun 9, 2020 • edited Loading

Codecov Report

cwgoes left a comment

Choose a reason for hiding this comment

fedekunze left a comment

Choose a reason for hiding this comment

ethanfrey commented Jun 9, 2020

cwgoes commented Jun 9, 2020

fedekunze left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cwgoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdityaSripal Jun 10, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fedekunze left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cwgoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cwgoes commented Jun 12, 2020

fedekunze commented Jun 12, 2020

AdityaSripal commented Jun 9, 2020 •

edited

Loading

codecov bot commented Jun 9, 2020 •

edited

Loading

AdityaSripal Jun 10, 2020 •

edited

Loading