* Update docs references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update DOCS_README to reflect current reality
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update vuepress config with current versions and updated discussions link
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update generated docs versions
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update docs build to use temp folder instead of home
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Document build-docs Makefile target
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add serve-docs Makefile target to serve local build of docs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Ensure 404 page is copied during docs build
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Redirect /master/ to /main/
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Attempt to resolve#7908
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update OpenAPI references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update CHANGELOG references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update Docker readme references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update UPGRADING references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update package-specific documentation references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update spec references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all code comment references to docs site from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Build v0.34.x as "latest"
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Explicitly mark v0.34 docs as latest in version selector
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all links from docs.tendermint.com/main to docs.tendermint.com/latest
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* ci: Redeploy docs on pushes to v0.34.x
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Temporarily copy spec directory into docs while building
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add nav link to main and clearly mark as unstable
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Revert to only publishing docs in nav for v0.34 and v0.33 with no latest
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Link to docs.tendermint.com/v0.34 from RFCs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Rather just use main for all docs.tendermint.com references on main branch
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Rename GitHub tree links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update link for ABCI Rust client
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update github links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update badges in root readme
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove codecov badge since we do not use it any more
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove Java and Kotlin tutorials
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove specs from docs build
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Migrate spec links to GitHub repo from docs site
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove references to non-existent PEX reactor spec
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Fix linting badge in README
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Signed-off-by: Thane Thomson <connect@thanethomson.com>
The `mockery` project recommends against using a binary of `mockery` that has been created using `go install`. https://github.com/vektra/mockery/pull/456. Developers of Tendermint wishing to generate mocks should avoid having a version of `mockery` on their path that does not match the version listed in [mockery_generate.sh](10e1ac8fea/scripts/mockery_generate.sh (L11)). To make this easier for developers, the `mockery_generate.sh` script uses a containerized copy of `mockery` if `mockery` is not present on the developer's `PATH`. This containerized version of `mockery` uses the same version of mockery as our CI pipelines and allows all developers to automatically use the same version without having to manage it themselves.
#### PR checklist
- [ ] Tests written/updated, or no tests needed
- [ ] `CHANGELOG_PENDING.md` updated, or no changelog entry needed
- [ ] Updated relevant documentation (`docs/`) and code comments, or no
documentation updates needed
## Description
Check block protocol version in header validate basic.
I tried searching for where we check the P2P protocol version but was unable to find it. When we check compatibility with a node we check we both have the same block protocol and are on the same network, but we do not check if we are on the same P2P protocol. It makes sense if there is a handshake change because we would not be able to establish a secure connection, but a p2p protocol version bump may be because of a p2p message change, which would go unnoticed until that message is sent over the wire. Is this purposeful?
Closes: #4790
## Description
This PR wraps the stdlib sync.(RW)Mutex & godeadlock.(RW)Mutex. This enables using go-deadlock via a build flag instead of using sed to replace sync with godeadlock in all files
Closes: #3242
Closes#4934
* light: do not compare trusted header w/ witnesses
we don't have trusted state to bisect from
* check header before checking height
otherwise you can get nil panic
Since the light client work introduced in v0.33 it appears full nodes
are no longer fully verifying commit signatures during block execution -
they stop after +2/3. See in VerifyCommit:
0c7fd316eb/types/validator_set.go (L700-L703)
This means proposers can propose blocks that contain valid +2/3
signatures and then the rest of the signatures can be whatever they
want. They can claim that all the other validators signed just by
including a CommitSig with arbitrary signature data. While this doesn't
seem to impact safety of Tendermint per se, it means that Commits may
contain a lot of invalid data. This is already true of blocks, since
they can include invalid txs filled with garbage, but in that case the
application knows they they are invalid and can punish the proposer. But
since applications dont verify commit signatures directly (they trust
tendermint to do that), they won't be able to detect it.
This can impact incentivization logic in the application that depends on
the LastCommitInfo sent in BeginBlock, which includes which validators
signed. For instance, Gaia incentivizes proposers with a bonus for
including more than +2/3 of the signatures. But a proposer can now claim
that bonus just by including arbitrary data for the final -1/3 of
validators without actually waiting for their signatures. There may be
other tricks that can be played because of this.
In general, the full node should be a fully verifying machine. While
it's true that the light client can avoid verifying all signatures by
stopping after +2/3, the full node can not. Thus the light client and
full node should use distinct VerifyCommit functions if one is going to
stop after +2/3 or otherwise perform less validation (for instance light
clients can also skip verifying votes for nil while full nodes can not).
See a commit with a bad signature that verifies here: 56367fd. From what
I can tell, Tendermint will go on to think this commit is valid and
forward this data to the app, so the app will think the second validator
actually signed when it clearly did not.
