Merge branch 'main' of github.com:cosmic-horizon/QWOYN into develop

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, sexual identity and orientation, or species.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming, encouraging, and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community and the planet
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when
+an individual is representing the project or its community in public spaces.
+Examples of representing a project or community include using an official
+project e-mail address, posting via an official social media account, or acting
+as an appointed representative at an online or offline event. Representation of
+a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

RELEASE_PROCESS.md

@@ -0,0 +1,99 @@
+# Release Process
+
+This document outlines the process for releasing new versions of Qwoyn Blockchain.
+
+## Semantic Versioning
+
+Qwoyn Blockchain follows [Semantic Versioning](https://semver.org/):
+
+> 1. MAJOR version when you make incompatible API changes
+> 1. MINOR version when you add functionality in a backwards compatible manner
+> 1. PATCH version when you make backwards compatible bug fixes
+
+Within the context of a blockchain application, we amend the summary to include the following:
+
+1. MAJOR version when you make incompatible API and client changes
+1. MINOR version when you make incompatible state machine changes and backwards compatible API and client changes 
+1. PATCH version when you make backwards compatible bug fixes not affecting the API, client, and state machine
+
+## Major Release Process
+
+A major release is an increment of the first number in the version tag (e.g. `v1.1.1` → `v2.0.0`).
+
+A major release has no restrictions on what changes it can or cannot include but frequent incompatible API and client changes should not be introduced lightly. Upgrading a live network to a major release requires a coordinated effort among many stakeholders. For more information about upgrading a live network, see [Upgrade Overview](https://docs.cosmic-horizon.com/qwoyn-blockchain/networks/mainnet/migrations/upgrade).
+
+Prior to each major release, at least one beta release and one release candidate must be published. The tag of each pre-release must include a sequence number scoped to the phase of the release. For example, the pre-releases leading up to an official `v2.0.0` release must occur in the following order with the following format:
+
+```
+v2.0.0-beta1 → v2.0.0-beta2 → ... → v2.0.0-rc1 → v2.0.0-rc2 → ... → v2.0.0
+```
+
+The release process for a major release starts once all changes for the major release have been implemented on the `main` branch. The release process is divided into three phases: beta release, release candidate, and official release.
+
+### Beta Release
+
+- Tag a beta release on the `main` branch and prevent any further changes unrelated to the release.
+  - When tagging a beta release, use an annotated git tag (e.g. `git tag -a v2.0.0-beta1`).
+- Perform an audit of all new changes and add additional automated tests and test cases if needed.
+- Perform a software upgrade on a temporary test network and all manual tests against that network.
+- If any issues are found, implement the necessary changes and then start over with a new beta release.
+- If no issues were found, move on to the next phase of the release.
+
+### Release Candidate
+
+- Create a new release branch from `main` using the format `release/vX` for the branch name.
+- Ensure the release branch is protected so that pushes are only permitted by the release managers.
+- Add a backport label with the format `backport/vX` and update the mergify backport integration.
+- In the release branch, update `CHANGELOG.md` to reflect the changes for the release candidate.
+  - The first release candidate must include all changes since the last official release.
+  - All other release candidates must include all changes since the last release candidate.
+- In the release branch, tag a release candidate and prevent any further changes unrelated to the release.
+  - When tagging a release candidate, use an annotated git tag (e.g. `git tag -a v2.0.0-rc1`).
+  - Once a release candidate has been tagged, the `main` branch is no longer restricted to release changes.
+- Push the release tag and update the release description to include the changes for the release candidate.
+- Perform an audit of all new changes and add additional automated tests and test cases if needed.
+- Perform a software upgrade on a temporary test network and all manual tests against that network.
+- If any issues are found, implement the necessary changes and then start over with a new release candidate.
+  - Any changes made at this stage should be done on `main` and then backported to the release branch.
+- If no issues were found, move on to the next phase of the release.
+
+### Official Release
+
+- In the `main` branch, update `CHANGELOG.md` to reflect the changes for the official release.
+  - The official release must include all changes since the last official release.
+  - The updates should be merged to `main` and then backported to the release branch.
+- In the release branch, tag the official release using an annotated git tag (e.g. `git -a v2.0.0`).
+- Push the release tag and update the release description to include the changes for the official release.
+
+## Minor Release Process
+
+A minor release is an increment of the second number in the version tag (e.g. `v1.1.1 → v1.2.0`).
+
+**A minor release must not introduce incompatible API and client changes.**
+
+Any changes to a release branch should be done on `main` and then backported to the release branch. The process for a minor release may vary depending on the number and significance of the changes made.
+
+- Perform an audit of all new changes and add additional automated tests and test cases if needed.
+- Perform a software upgrade on a temporary test network and all manual tests against that network.
+- If any issues are found, implement the necessary changes and then start over.
+- In the `main` branch, update `CHANGELOG.md` to reflect the changes for the minor release.
+  - The minor release must include all changes since the last release.
+  - The updates should be merged to `main` and then backported to the release branch.
+- In the release branch, tag the minor release using an annotated git tag (e.g. `git -a v1.2.0`).
+- Push the release tag and update the release description to include the changes for the minor release.
+
+## Patch Release Process
+
+A patch release is an increment of the third number in the version tag (e.g. `v1.1.1` → `v1.1.2`).
+
+**A patch release must not introduce incompatible API, client, or state machine changes.**
+
+Any changes to a release branch should be done on `main` and then backported to the release branch. The process for a patch release may vary depending on the number and significance of the changes made.
+
+- Perform an audit of all new changes and add additional automated tests and test cases if needed.
+- If any issues are found, implement the necessary changes and then start over.
+- In the `main` branch, update `CHANGELOG.md` to reflect the changes for the patch release.
+  - The patch release must include all changes since the last release.
+  - The updates should be merged to `main` and then backported to the release branch.
+- In the release branch, tag the patch release using an annotated git tag (e.g. `git -a v1.1.2`).
+- Push the release tag and update the release description to include the changes for the patch release.

SECURITY.md

@@ -0,0 +1,91 @@
+# Security
+
+**Do not open up a public GitHub issue when reporting a security vulnerability. Please report security vulnerabilities by email from a secure email address to [email protected].**
+
+Qwoyn Blockchain is built on top of Cosmos SDK and Tendermint Core. Please refer to the security policy for each of these projects if the security vulnerability is not specific to Qwoyn Blockchain:
+
+- [Cosmos SDK Security Policy](https://github.com/cosmos/cosmos-sdk/blob/main/SECURITY.md)
+- [Tendermint Core Security Policy](https://github.com/tendermint/tendermint/blob/main/SECURITY.md)
+
+Significant security vulnerabilities within Qwoyn Blockchain are most likely to occur in the following packages:
+
+- [`/app`](https://github.com/cosmic-horizon/QWOYN/tree/main/app)
+- [`/types`](https://github.com/cosmic-horizon/QWOYN/tree/main/types)
+
+## Disclosure Process
+
+The Qwoyn Blockchain team uses the following disclosure process:
+
+1. After a security report is received, the Qwoyn Blockchain team works to verify the issue and confirm its severity level using Common Vulnerability Scoring System (CVSS).
+1. The Qwoyn Blockchainteam collaborates with the Cosmos SDK and Tendermint teams to determine the vulnerability’s potential impact on the other applications and services in the Cosmos ecosystem.
+1. Patches are prepared in private repositories for eligible releases. See [Release Process](https://github.com/cosmic-horizon/QWOYN/blob/main/RELEASE_PROCESS.md) for more information about 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 partner projects and validators.
+1. 24 hours after the notification, fixes are applied publicly and the new release is issued.
+1. After a release is available, 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. One week after the release goes out, we publish a postmortem with details about and our response to the vulnerability.
+
+This process can take some time. Every possible effort is made to handle the security vulnerability in a timely a manner. However, it's important that we follow this security process to ensure that disclosures are handled consistently and to keep Qwoyn Blockchain and its partner projects 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 the following:
+
+```text
+Dear Qwoyn Blockchain partners,
+
+A critical security vulnerability has been identified in Qwoyn Blockchain 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 Qwoyn Blockchain vX.X.Y to fix the security vulnerability.
+
+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 may 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  (QWOYN BLOCKCHAIN ENG)
+1. Write “Security Advisory” for forum (QWOYN BLOCKCHAIN LEAD)
+
+#### 24 Hours Before Release Time
+
+1. Post “Security Advisory” pre-notification on forum (QWOYN BLOCKCHAIN 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 partner projects or other users (PARTNERSHIPS LEAD)
+
+#### Release Time
+
+1. Cut Qwoyn Blockchain release for eligible version (QWOYN BLOCKCHAIN ENG)
+1. Post “Security release” on forum (QWOYN BLOCKCHAIN LEAD)
+1. Post new Tweet linking to forum post (COMMS LEAD)
+1. Remind everyone on 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 (QWOYN BLOCKCHAIN LEAD)
+
+#### 7 Days After Release Time
+
+1. Publish CVE if it has not yet been published (ADMIN)
+1. Publish forum post with exploit details (QWOYN BLOCKCHAIN ENG, QWOYN BLOCKCHAIN LEAD)

install.md

@@ -26,7 +26,7 @@ sudo apt update
 sudo apt install build-essential jq wget git -y
 
 wget https://dl.google.com/go/go1.18.1.linux-amd64.tar.gz
-tar -xvf go1.18.1.linux-amd64.tar.gz
+tar -xvf go1.19.5.linux-amd64.tar.gz
 sudo mv go /usr/local
 ```
 
@@ -53,10 +53,10 @@ git clone https://github.com/cosmic-horizon/QWOYN.git
 
 # Install `qwoynd`
 cd QWOYN
-git checkout v1.0.0-beta
+git checkout v1.0.0
 make install
 
-# check version (1.0.0-beta)
+# check version (1.0.0)
 qwoynd version
 ```
 

scripts/completions.sh

@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+rm -rf completions
+mkdir completions
+
+for sh in bash zsh fish; do
+	go run cmd/regen/main.go completion "$sh" >"completions/regen.$sh"
+done

scripts/generate_cli_docs.go

@@ -0,0 +1,18 @@
+package main
+
+import (
+	"log"
+
+	"github.com/spf13/cobra/doc"
+
+	"github.com/regen-network/regen-ledger/v5/app/client/cli"
+)
+
+// generate documentation for all regen app commands
+func main() {
+	rootCmd, _ := cli.NewRootCmd()
+	err := doc.GenMarkdownTree(rootCmd, "commands")
+	if err != nil {
+		log.Fatal(err)
+	}
+}