Merge branch 'master' into cyberbono3/8179-add-env-vars

CHANGELOG.md

@@ -53,6 +53,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
   * updated the keyring display structure (it uses protobuf JSON serialization) - the output is more verbose.
   * Renamed `MarshalAny` and `UnmarshalAny` to `MarshalInterface` and `UnmarshalInterface` respectively. These functions must take an interface as parameter (not a concrete type nor `Any` object). Underneath they use `Any` wrapping for correct protobuf serialization.
   * CLI: removed `--text` flag from `show-node-id` command; the text format for public keys is not used any more - instead we use ProtoJSON.
+* (types) [\#9079](https://github.com/cosmos/cosmos-sdk/issues/9079) Add `AddAmount`/`SubAmount` methods to `sdk.Coin`.
 
 ### API Breaking Changes
 

SECURITY.md

@@ -52,3 +52,81 @@ the code.
 - HD key derivation, local and Ledger, and all key-management functionality
 - Side-channel attack vectors with our implementations
   - e.g. key exfiltration based on time or memory-access patterns when decrypting privkey
+
+## Disclosure Process
+
+The Cosmos SDK team uses the following disclosure process:
+
+1. After a security report is received, the Cosmos SDK team works to verify the issue and confirm its severity level using Common Vulnerability Scoring System (CVSS).
+1. The Cosmos SDK team collaborates with the Tendermint and Gaia teams to determine the vulnerability’s potential impact on the Cosmos Hub and partners.
+1. Patches are prepared in private repositories for eligible releases of Cosmos SDK. See [Stable Releases](https://github.com/cosmos/cosmos-sdk/blob/master/STABLE_RELEASES.md) for a list of eligible releases.
+1. If it is determined that a CVE-ID is required, we request a CVE through a CVE Numbering Authority.
+1. We notify the community that a security release is coming to give users time to prepare their systems for the update. Notifications can include forum posts, tweets, and emails to partners and validators.
+1. 24 hours after the notification, fixes are applied publicly and new releases are issued.
+1. The Gaia team updates their Tendermint Core and Cosmos SDK dependencies to use these releases and then issues new Gaia releases.
+1. After releases are available for Tendermint Core, Cosmos SDK, and Gaia, we notify the community again through the same channels. We also publish a Security Advisory on Github and publish the CVE, as long as the Security Advisory and the CVE do not include information on how to exploit these vulnerabilities beyond the information that is available in the patch.
+1. After the community is notified, Tendermint pays out any relevant bug bounties to submitters.
+1. One week after the releases go out, we publish a post with details and our response to the vulnerability.
+
+This process can take some time. Every effort is made to handle the bug in as timely a manner as possible. However, it's important that we follow this security process to ensure that disclosures are handled consistently and to keep Cosmos SDK and its downstream dependent projects--including but not limited to Gaia and the Cosmos Hub--as secure as possible.
+
+### Disclosure Communications
+
+Communications to partners usually include the following details:
+1. Affected version or versions
+1. New release version
+1. Impact on user funds
+1. For timed releases, a date and time that the new release will be made available
+1. Impact on the partners if upgrades are not completed in a timely manner
+1. Potential required actions if an adverse condition arises during the security release process
+
+An example notice looks like:
+```
+Dear Cosmos SDK partners,
+
+A critical security vulnerability has been identified in Cosmos SDK vX.X.X. 
+User funds are NOT at risk; however, the vulnerability can result in a chain halt.
+
+This notice is to inform you that on [[**March 1 at 1pm EST/6pm UTC**]], we will be releasing Cosmos SDK vX.X.Y to fix the security issue. 
+We ask all validators to upgrade their nodes ASAP.
+
+If the chain halts, validators with sufficient voting power must upgrade and come online for the chain to resume.
+```
+
+### Example Timeline
+
+The following timeline is an example of triage and response. Each task identifies the required roles and team members; however, multiple people can play each role and each person may play multiple roles.
+
+#### 24+ Hours Before Release Time
+
+1. Request CVE number (ADMIN)
+1. Gather emails and other contact info for validators (COMMS LEAD)
+1. Test fixes on a testnet  (COSMOS SDK ENG)
+1. Write “Security Advisory” for forum (COSMOS SDK LEAD)
+
+#### 24 Hours Before Release Time
+
+1. Post “Security Advisory” pre-notification on forum (COSMOS SDK LEAD)
+1. Post Tweet linking to forum post (COMMS LEAD)
+1. Announce security advisory/link to post in various other social channels (Telegram, Discord) (COMMS LEAD)
+1. Send emails to partners or other users (PARTNERSHIPS LEAD)
+
+#### Release Time
+
+1. Cut Cosmos SDK releases for eligible versions (COSMOS SDK ENG)
+1. Cut Gaia release for eligible versions (GAIA ENG)
+1. Post “Security releases” on forum (COSMOS SDK LEAD)
+1. Post new Tweet linking to forum post (COMMS LEAD)
+1. Remind everyone using social channels (Telegram, Discord)  that the release is out (COMMS LEAD)
+1. Send emails to validators and other users (COMMS LEAD)
+1. Publish Security Advisory and CVE if the CVE has no sensitive information (ADMIN)
+
+#### After Release Time
+
+1. Write forum post with exploit details (COSMOS SDK LEAD)
+1. Approve payout on HackerOne for submitter (ADMIN)
+
+#### 7 Days After Release Time
+
+1. Publish CVE if it has not yet been published (ADMIN)
+1. Publish forum post with exploit details (COSMOS SDK ENG, COSMOS SDK LEAD)

docs/migrations/README.md

@@ -11,3 +11,4 @@ This folder contains all the migration guides to update your app and modules to
 1. [App and Modules Migration](./app_and_modules.md)
 1. [Chain Upgrade Guide to v0.40](./chain-upgrade-guide-040.md)
 1. [REST Endpoints Migration](./rest.md)
+1. [Keyring Migration](./keyring.md)

docs/migrations/keyring.md

@@ -0,0 +1,31 @@
+<!--
+order: 4
+-->
+# Keyring Migrate Quick Start
+
+`keyring` is the Cosmos SDK mechanism to manage the public/private keypair. Cosmos SDK v0.42 (Stargate) introduced breaking changes in the keyring. 
+
+To upgrade your chain from v0.39 (Launchpad) and earlier to Stargate, you must migrate your keys inside the keyring to the latest version. For details on configuring and using the keyring, see [Setting up the keyring](../run-node/keyring.md).
+
+This guide describes how to migrate your keyrings.
+
+The following command migrates your keyrings:
+
+```bash
+Usage
+simd keys migrate <old_home_dir>
+```
+
+The migration process moves key information from the legacy db-based Keybase to the [keyring](https://github.com/99designs/keyring)-based Keyring. The legacy Keybase persists keys in a LevelDB database in a 'keys' sub-directory of the client application home directory (`old_home_dir`). For example, `$HOME/.gaiacli/keys/` for [Gaia](https://github.com/cosmos/gaia).
+
+You can migrate or skip the migration for each key entry found in the specified  `old_home_dir` directory. Each key migration requires a valid passphrase. If an invalid passphrase is entered, the command exits. Run the command again to restart the keyring migration. 
+
+The `migrate` command takes the following flags:
+- `--dry-run` boolean
+
+     - true - run the migration but do not persist changes to the new Keybase. 
+     - false - run the migration and persist keys to the new Keybase. 
+
+Recommended: Use `--dry-run true` to test the migration without persisting changes before you migrate and persist keys. 
+
+- `--keyring-backend` string flag. It allows you to select a backend. For more detailed information about the available backends, you can read [the keyring guide](../run-node/keyring.md).