Pitfalls in Cosmos-SDK versions detection logic

[mzabaluev]

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 the cosmos.base.tendermint.v1beta1.VersionInfo protobuf response, and finds matches with known names of the components. The versions are checked against compatibility requirements using the VersionReq API provided by the semver crate.

There are following issues with the present logic:

• The module names are matched by a substring match on the GitHub repository path of the respective component. This is too loose because some 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 Add support for fetching & parsing the Tendermint version of a chain #2302 (comment)
• The constraint syntax used by semver 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 of semver 1.0.10). The workaround currently implemented (in Treat pre-releases of the Cosmos SDK as their standard version in compatibility check #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

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[adizere]

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.