Special thanks to external contributors on this release:

Friendly reminder, we have a [bug bounty program](https://hackerone.com/tendermint).

- [privval] \#5239 Add `chainID` to requests from client.

This code of conduct applies to all projects run by the Tendermint/COSMOS team and hence to tendermint.

* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

These are the policies for upholding our community’s standards of conduct. If you feel that a thread needs moderation, please contact the above mentioned person.

1. Remarks that violate the Tendermint/COSMOS standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.)

To install `gogoproto`, do the following:

You should now be able to run `make proto-gen` from inside the root Tendermint directory to generate new files from proto files.

NOTE: In case you installed Vagrant in 2017, you might need to run

`vagrant box update` to upgrade to the latest `ubuntu/xenial64`.

vagrant up

vagrant ssh

make test

You can do this by cherry-picking your commit off master:

$ git checkout rc1/v0.33.5

$ git checkout -b {new branch name}

$ git cherry-pick {commit SHA from master}

We follow the [Go style guide on commit messages](https://tip.golang.org/doc/contribute.html#commit_messages). Write concise commits that start with the package name and have a description that finishes the sentence "This change modifies Tendermint to...". For example,

cmd/debug: execute p.Signal only when p is not nil

[potentially longer description in the body]

The Dockerfile for tendermint is not expected to change in the near future. The master file used for all builds can be found [here](https://raw.githubusercontent.com/tendermint/tendermint/master/DOCKER/Dockerfile).

- **Supported Docker versions:** [the latest release](https://github.com/moby/moby/releases) (down to 1.6 on a best-effort basis)

The design goals for Tendermint (and the SDK and related libraries) are:

Legibility is key to maintaining bug-free software as it evolves toward more

optimizations, more ease of debugging, and additional features.

assess the correctness of such a for-loop by visual inspection.

It doesn't matter whether there are alternative implementations that are 2x or

3x more performant, when the software doesn't work, deadlocks, or if bugs

for future implementations.

In order to create maintainable, forward-optimizable software, it is critical

to develop well-encapsulated objects that have well understood properties, and

in both concurrent and non-concurrent logic, and due to its well encapsulation,

it's easy to get the usage of the mutex right.

`The default Source is safe for concurrent use by multiple goroutines, but

Sources created by NewSource are not`. The reason why the default

package-level source is safe for concurrent use is because it is protected (see

But we shouldn't rely on the global source, we should be creating our own

Rand/Source instances and using them, especially for determinism in testing.

the design of abstractions that should be revisited.

In order for Tendermint to remain relevant in the years to come, it is vital

for Tendermint to take advantage of multicore architectures. Due to the nature

request handling.

Here are some guidelines for designing for (sufficient) performance and concurrency:

needs to get addressed sooner than later. Avoid creating too many

goroutines as a patch around incomplete concurrency design, or at least be

aware of the debt and do not invest in the debt. On the other hand, Tendermint

is designed to have a limited number of peers (e.g. 10 or 20), so the creation

of O(C) goroutines per O(P) peers is still O(C\*P=constant).

try to create more modular functions that do make use of defer statements.

* Premature optimization kills

* Readability is paramount

[](https://github.com/moovweb/gvm)

[](https://discord.gg/AzefAFd)

[](https://github.com/tendermint/tendermint/blob/master/LICENSE)

[](https://sourcegraph.com/github.com/tendermint/tendermint?badge)

| Branch | Tests | Coverage | Linting |

| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |

Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine - written in any programming language -

and securely replicates it on many machines.

- config

- node

- libs

Exported objects in these packages that are not covered by the versioning scheme

are explicitly marked by `// UNSTABLE` in their go doc comment and may change at any

[Tendermint specification](https://docs.tendermint.com/master/spec/).

For details on using the software, see the [documentation](/docs/) which is also

As part of our [Coordinated Vulnerability Disclosure

Policy](https://tendermint.com/security), we operate a [bug

bounty](https://hackerone.com/tendermint).

* Work with you to understand, resolve and ultimately disclose the issue in a timely fashion

Tendermint Core uses the following disclosure process:

1. Once a security report is received, the Tendermint Core team works to verify the issue and confirm its severity level using CVSS.

This process can take some time. Every effort will be made to handle the bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently and to keep Tendermint Core and its downstream dependent projects--including but not limited to Gaia and the Cosmos Hub--as secure as possible.

The following is an example timeline for the triage and response. The required roles and team members are described in parentheses after each task; however, multiple people can play each role and each person may play multiple roles.

4. Send emails to validators or other users (PARTNERSHIPS LEAD)

1. Cut Tendermint releases for eligible versions (TENDERMINT ENG, TENDERMINT LEAD)

2. Cut Cosmos SDK release for eligible versions (COSMOS ENG)

3. Cut Gaia release for eligible versions (GAIA ENG)

8. Publish Security Advisory and CVE, if CVE has no sensitive information (ADMIN)

1. Write forum post with exploit details (TENDERMINT LEAD)

2. Approve pay-out on HackerOne for submitter (ADMIN)

1. Publish CVE if it has not yet been published (ADMIN)

2. Publish forum post with exploit details (TENDERMINT ENG, TENDERMINT LEAD)

The Tendermint Core team commits to releasing security patch releases for both the latest minor release as well for the major/minor release that the Cosmos Hub is running.

If you are running older versions of Tendermint Core, we encourage you to upgrade at your earliest opportunity so that you can receive security patches directly from the Tendermint repo. While you are welcome to backport security patches to older versions for your own use, we will not publish or promote these backports.

The full scope of our bug bounty program is outlined on our [Hacker One program page](https://hackerone.com/tendermint). Please also note that, in the interest of the safety of our users and staff, a few things are explicitly excluded from scope:

* Any third-party services

* Findings from physical testing, such as office access

* Findings derived from social engineering (e.g., phishing)

The following is a list of examples of the kinds of vulnerabilities that we’re most interested in. It is not exhaustive: there are other kinds of issues we may also be interested in!

* Core verification

* Bisection/sequential algorithms