Cosmos SDK / fork security v0.2.18 #1821
Priority: High release-candidate
Cosmos SDK fork security for v0.2.18. Nothing huge: targeted fork patches first, full rebase only if it stays in scope.
Chain-halt fixes can ship on the current v0.53.3-ps19 fork without waiting for v0.53.8. The rebase is a second, state-breaking step and needs its own test pass.
Needs thorough testing before merge.
Sub-issues
-
1708 chain-halt:
ValidatorByConsAddrreturnsErrNoValidatorFound(gonka-ai/cosmos-sdk#19) -
1205 chain-halt:
markValidatorForDeletionjailed-delete race (gonka-ai/cosmos-sdk#16) -
1719 ECIES: restore curve validation, reject short ciphertexts (gonka-ai/cosmos-sdk#20)
-
1671 rebase fork onto upstream v0.53.8
Related fork PRs
- gonka-ai/cosmos-sdk#14 stale consensus-key conflicts
- gonka-ai/cosmos-sdk#17 skip tombstoned validators in epoch recompute
- gonka-ai/cosmos-sdk#10 snapshot chunk deletion during state sync (see also #632)
💬 Comments (1)
🔄 Auto-synced from Issue #1821 every hour.
Local test pass over the fork PRs listed here, since the fork's own CI doesn't run them (every job on outside PRs sits
action_required/cancelled, and most jobs were cancelled on #18 too). Environment: WSL, go1.24.2,gonka-ai/cosmos-sdkrelease/v0.53.x@c8229ef61(=v0.53.3-ps19-observability, the tag inference-chain pins). Details are in each PR:ValidatorByConsAddr→(nil, nil)): its tests fail on the base and pass on the PR. The evidence path is fixed. The slashing path still returnsErrNoValidatorFoundone call earlier, viaIsValidatorJailedinHandleValidatorSignature(integration test in the PR comment).markValidatorForDeletion): both tests fail on the base and pass on the PR. A multi-block run shows the removed validator stays resolvable for at least 5 EndBlocks, so there's no early deletion inside CometBFT's update lag.SetTombstoneChecker(app.SlashingKeeper.IsTombstoned)wiring lands ininference-chain/app.store/v1.1.2-psNtag to reach inference-chain.The chain-halt set composes: #14, #16, #17 and #19 merge cleanly together. On the combined branch, all of their own tests pass. The full root module (
x/...,baseapp,types) plustests/integration/...fails exactly the same tests asrelease/v0.53.xalone. The one extra failure in the first run,x/distribution/simulationTestSimulateMsgWithdrawValidatorCommission, flakes 2/5 on the base as well.One thing that limits "thorough testing" of anything in the fork:
release/v0.53.xitself fails 69 top-level tests (72 subtests) across 18 packages: -x/{bank,distribution,gov,slashing,staking}(keeper and simulation),types,types/bech32/legacybech32-tests/integration/{distribution,evidence,gov,slashing,staking}The failures I traced are stock-SDK expectations of paths the fork disabled on purpose:
MsgDelegate/MsgUndelegate/MsgBeginRedelegate/MsgCancelUnbondingDelegationreturn "is disabled",RemoveValidatorTokensAndShares is disabled after genesis in Proof of Compute mode, and the no-op bank keeper leaves balances untouched. I haven't classified all 69, andtypes/legacybech32in particular I didn't look into. In this state the unit suites can't flag a regression, because every package that matters is already red.If it's useful, I can open a test-only PR against
release/v0.53.xthat marks the by-design divergences witht.Skipand a one-line reason each, and lists anything that doesn't fit that pattern for someone to look at. That would make a green baseline to test fork patches against. Happy to take a different approach if you'd rather delete those tests or keep them as they are.