Open mzabaluev opened 2 years ago
perhaps, it's best to treat pre-release components specially and emit a log warning whenever they are encountered, but otherwise relax the compatibility check.
This is a great idea. We should definitely add a warning when encountering an RC/prerelease dependency, at the very least to flag to operators that the networks they're relaying on have (potentially) unstable software.
Summary of Bug
The logic used to discover versions of Cosmos-SDK, IBC-go, and Tendermint used by a Cosmos node should be made more robust.
Version
0.15.0
Details
The relayer logic used to extract versions of modules the node is built on in
chain::cosmos::version
has several potential problems. It looks at the Go dependencies list as returned in thecosmos.base.tendermint.v1beta1.VersionInfo
protobuf response, and finds matches with known names of the components. The versions are checked against compatibility requirements using theVersionReq
API provided by thesemver
crate.There are following issues with the present logic:
tendermint/tendermint-foo
module would be mistaken as Tendermint-Go. At the same time, it's not a reliable technique to match forked modules, a wish expressed in https://github.com/informalsystems/ibc-rs/pull/2302#discussion_r898877379semver
applies dependency checking rules used by Cargo, which have some peculiarities. In particular, it treats any versions with a pre-release component as isolated and incompatible with any range constraints (as ofsemver
1.0.10). The workaround currently implemented (in #1357) is to erase the pre-release component, which opens potential for declaring a node compatible when it in fact isn't (case in point: a node based on Cosmos-SDK 0.46.0-pre.2 will likely not be compatible with the eventual Cosmos SDK 0.46 protocols). In general, perhaps, it's best to treat pre-release components specially and emit a log warning whenever they are encountered, but otherwise relax the compatibility check.For Admin Use