From 87cc91d67d8d376eea506745eb00c5a60ade5072 Mon Sep 17 00:00:00 2001 From: Daniel Pittman Date: Sun, 5 Feb 2023 23:14:28 -0700 Subject: [PATCH] added docs --- CODE_OF_CONDUCT.md | 76 ++++++++++++ CONTRIBUTING.md | 245 ++++++++++++++++++++++++++++++++++++++ RELEASE_PROCESS.md | 99 +++++++++++++++ SECURITY.md | 91 ++++++++++++++ startport-instructions.md | 56 --------- 5 files changed, 511 insertions(+), 56 deletions(-) create mode 100644 CODE_OF_CONDUCT.md create mode 100644 CONTRIBUTING.md create mode 100644 RELEASE_PROCESS.md create mode 100644 SECURITY.md delete mode 100644 startport-instructions.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..33950af --- /dev/null +++ b/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 office@cosmic-horizon.com. 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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..8327277 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,245 @@ +# Contributing + +Qwoyn Blockchain is the open-source backbone of games such as [Cosmic Horizon](https://cosmic-horizon.com) and contributions to this codebase is appreciated. To contribute to this project, please follow the rules and guidelines below. + +We follow an agile methodology and use ZenHub and [GitHub Issues](https://github.com/cosmic-horizon/QWOYN/issues) for ticket tracking. To understand our current priorities and roadmap, check out [GitHub Milestones](https://github.com/cosmic-horizon/QWOYN/milestones). If you're a first time contributor, check out issues labeled "[good first issue](https://github.com/cosmic-horizon/QWOYN/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+)". + +If you have questions about a specific issue or you would like to start working on an issue, please comment in the issue. If you have general questions, feel free to reach out in the **#community-dev** channel of our [Discord Server](https://discord.cosmic-horizon.com). + +Before you begin your journey, please read [Code of Conduct](CODE_OF_CONDUCT.md). Also, please do your best to search for answers before asking what may seem like common questions, and we will do our best to update our documentation to include the answers. + +### Table of Contents + +- [General Guidelines](#general-guidelines) + - [Submitting Issues](#submitting-issues) + - [Reviewing Proposals](#reviewing-proposals) + - [Submitting Pull Requests](#submitting-pull-requests) + - [Reviewing Pull Requests](#reviewing-pull-requests) + - [Using GitHub Labels](#using-github-labels) + - [Using Semantic Commits](#using-semantic-commits) +- [Coding Guidelines](#coding-guidelines) + - [Writing Proto Files](#writing-proto-files) + - [Writing Feature Files](#writing-feature-files) + - [Writing Golang Code](#writing-golang-code) + - [Writing Golang Tests](#writing-golang-tests) +- [Documentation Guidelines](#documentation-guidelines) + - [Writing Guidelines](#writing-guidelines) + - [Writing Documentation](#writing-documentation) + - [Writing Specifications](#writing-specifications) + +### Recommended Reading + +- [Qwoyn Blockchain Docs](https://docs.cosmic-horizon.com) +- [Cosmos SDK Docs](https://docs.cosmos.network/) + +### Additional Documentation + +- [Code of Conduct](CODE_OF_CONDUCT.md) +- [Release Process](RELEASE_PROCESS.md) +- [Security Policy](SECURITY.md) + +## General Guidelines + +The following guidelines cover the basics, including submitting issues and pull requests, reviewing proposals and pull requests, and using labels and semantic commits. + +### Submitting Issues + +Please use the GitHub interface and [the provided templates](https://github.com/cosmic-horizon/QWOYN/issues/new/choose) when submitting a new issue. + +#### For Bugs + +***Important: Do not open up a GitHub issue when reporting a security vulnerability. Reporting security vulnerabilities must go through the process defined within our [security policy](SECURITY.md).*** + +Please make sure you do the following: +- provide a concise description of the issue +- provide a git commit hash or release version +- provide steps on how to reproduce the issue + +#### For Features + +Issues for features should have a clear user story or user story breakdown. The whole development process affects the quality of the work that ends up in a pull request, starting with a user story. + +Please make sure you do the following: +- provide a concise description of the feature +- provide a rationale for including the feature +- provide a description of the requirements + +### Reviewing Proposals + +When reviewing a feature request, please be conscientious of the proposer and the work they put into submitting the request. If you disagree with the feature or the approach, make sure you provide constructive feedback and clearly explain your rationale. + +### Submitting Pull Requests + +In addition to the guidelines here, please review [Coding Guidelines](#coding-guidelines) and/or [Documentation Guidelines](#documentation-guidelines) before submitting a pull request. + +Ideally a pull request addresses a single issue. In some cases a pull request may address multiple issues or a pull request may not have a corresponding issue. If the necessity of the change is not obvious, please open an issue first. + +Another way of framing this, "One pull request, one concern." A pull request to fix a bug should only fix a bug, a pull request to add a new feature should only add a new feature, a pull request to refactor code should only refactor code, etc. + +#### Getting Started + +Unless you are a core team member or a contributor who has been granted limited write access, you will first need to fork the repository before you can submit a pull request. To fork the repository, [click this link](https://github.com/cosmic-horizon/QWOYN/fork), select the owner, and then click "Create fork". + +Once you have forked the repository, you can clone the repository, create a feature branch, and start making changes locally. If you have any questions about how to use Git with GitHub, we recommend checking out [GitHub Git Guides](https://github.com/git-guides). + +If you are making documentation changes to a single page, you can also use the GitHub editor. For example, to edit this document, you would click the edit icon in the top right corner, make the changes, scroll to the bottom, and fill out and submit "Commit changes". + +#### Feature Branch + +The feature branch should follow the format `/-`: + +- `author` - your first name or username (should be unique, consistent, and non-ambiguous) +- `issue-number` - the issue number that the feature branch is addressing (if applicable) +- `description` - a very concise description of the changes (should be no more than a few words) + +#### Requesting Reviews + +Core team members will automatically be assigned to review each pull request upon submission based on [CODEOWNERS](.github/CODEOWNERS). If the pull request is not ready for an official review, open the pull request as a draft and keep it open as a draft until it is ready. If you would like initial feedback on a draft pull request, leave a comment tagging the individual requesting initial feedback. + +Before opening a pull request (either directly or converting from draft), please make sure you have added a description and that you have read through and completed the "Author Checklist" items within the pull request template. + +### Reviewing Pull Requests + +Before approving a pull request, please make sure you have read through and completed the "Reviewer Checklist" items within the pull request template, or you have checked off the individual items that you have reviewed. + +In addition, reviewers should use one of the following keywords in the review comment: + +- ACK or LGTM - you reviewed the changes, they look good, and testing does not apply (usually with an approval) +- cACK - "Concept ACK" - you agree with the idea or direction but haven't done a thorough review (usually without an approval) +- utACK - "Untested ACK" - you reviewed the changes but haven't performed any manual tests (usually with an approval) +- tACK - "Tested ACK" - you reviewed the changes and performed the necessary manual tests (usually with an approval) + +### Using GitHub Labels + +We use [GitHub Labels](https://github.com/cosmic-horizon/QWOYN/labels) for issues and pull requests. The following provides some general guidelines for using labels. + +#### Using Labels With Issues + +- each issue should have one `Type` label +- each issue should have one `Scope` label +- each issue should have one `Status` label +- new issues should always start with either `Status: Proposed` or `Status: Bug` + +#### Using Labels With Pull Requests + +- `Type`, `Scope`, and `Status` labels are not required for pull requests because pull request titles must be written using semantic commits (i.e. the title should include the type and scope of the pull request) and because each pull request should have a corresponding issue with the appropriate `Type`, `Scope`, and `Status` labels applied + +### Using Semantic Commits + +The [semantic commit](https://www.semanticcommits.org/en/v1.0.0/) format is required for pull request titles, which will be used as the commit message with "squash and merge". The first commit of a new branch should be a semantic commit but semantic commits are not required for individual commits. + +General guidelines to keep in mind: + +- `build`, `ci`, and `chore` should only be used when updating non-production code +- `fix`, `feat`, `refactor`, and `perf` should only be used when updating production code +- `test` should only be used when updating tests +- `style` should only be used when updating format +- `docs` should only be used when updating documentation + +Also, to write useful commit message descriptions, it’s good practice to start with a verb, such as “add”, “remove”, "update", or “fix”. + +#### Pull Request Titles + +We use "squash and merge" when merging pull requests, which uses the title of the pull request as the merged commit. For this reason, pull requests titles must follow the format of semantic commits and should include the appropriate type and scope, and `!` should be added to the type prefix if the pull request introduces an API or client breaking change and will therefore require a major release. + +The appropriate type and scope of the pull request should be provided by the labels of the corresponding issue but the type and scope may need to be adjusted during the implementation. If the type and scope need to be adjusted during the implementation, the label used in the corresponding issue should be updated to reflect those changes. The format of the pull request title is verified during the CI process and the allowed type prefixes are defined in [this json file](https://github.com/commitizen/semantic-commit-types/blob/v3.0.0/index.json). + +The scope is not required and may be excluded if the pull request does not update any golang code within a go module but the scope should be included and should reflect the location of the go module whenever golang code within a go module is updated. Only one go module should be updated at a time but in some cases multiple go modules may be updated. In the case of multiple go modules being updated, the location of the updated go modules should be separated by a `,` and no spaces. + +For pull requests that update proto files, the scope should reflect the location of the go module within which the code will be generated. This is also the location of the go module in which a dummy implementation will be added when implementing new features and where changes will be made when updating existing features. Note, this use of scope in relation to updating proto files may change in the future. + +Examples of pull request titles using semantic commits: + +``` +docs: add examples to contributing guidelines +feat(x/ecocredit): add query for all credit classes +fix(x/data): update attest to store correct timestamp +refactor(x/ecocredit): update location to jurisdiction +style(x/data): format proto files and fix whitespace +perf(x/ecocredit): move redundant calls outside of for loop +test(x/data): implement acceptance tests for anchoring data +build: bump cosmos-sdk version to latest patch release +ci: add github action workflow for proto lint check +chore: delete test output and add to gitignore +``` + +#### Individual Commits + +It is not required that individual commits within a pull request use semantic commits but the first commit should be a semantic commit. The first commit message is used to auto-populate the pull request title when opening a new pull request. If the pull request only has one non-merge commit, the first commit is used to auto-populate the commit message when using "squash and merge". + +## Coding Guidelines + +The following guidelines are for writing code. + +### Writing Proto Files + +[ work in progress... check back soon ] + +### Writing Feature Files + +[ work in progress... check back soon ] + +#### Resources + +- [https://cucumber.io/docs/cucumber/](https://cucumber.io/docs/cucumber/) +- [https://leanpub.com/bddbooks-discovery](https://leanpub.com/bddbooks-discovery) +- [https://leanpub.com/bddbooks-formulation](https://leanpub.com/bddbooks-formulation) + +### Writing Golang Code + +The following are some general guidelines when writing golang code: + +- optimize for readability +- use tabs rather than spaces +- end of file should have an extra line +- imports should be alphabetical +- imports should be divided into sections with a line between each section + - native go packages + - external packages + - internal packages +- structs declared with more than two properties should be declared with a line for each property +- the first word in a comment should only be capitalized if the comment is a complete sentence or if the first word should be capitalized regardless of its location within the comment (e.g. if a public function name) +- comments should only use a period if the comment is a complete sentence +- when adding a comment to explain code, first consider changing the code to be more self documenting + +#### Module File Names + +- each message implementation should have its own file and include the full name of the proto message (e.g. `msg_create_class.go`) +- each message server method should have its own file and include the full name of the proto message and the method name should be prefixed with `msg_` to indicate the method is part of the message server (e.g. `msg_create_class.go`) +- each query server method should have its own file and include the full name of the proto message and the method name should be prefixed with `query_` to indicate the method is part of the query server (e.g. `query_class_info.go`) + +### Writing Golang Tests + +[ work in progress... check back soon ] + +## Documentation Guidelines + +The following guidelines are for writing documentation. + +### Writing Guidelines + +- Always double-check for spelling and grammar. +- Avoid using `code` format when writing in plain English. +- Try to express your thoughts in a clear and precise way. +- RFC keywords should be used in technical documentation (uppercase) and are recommended in user documentation (lowercase). The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). + +#### Resources + +- [https://developers.google.com/style](https://developers.google.com/style) +- [https://developers.google.com/tech-writing/overview](https://developers.google.com/tech-writing/overview) + +### Writing Documentation + +Qwoyn Blockchain documentation is hosted at [docs.cosmic-horizon.com](https://docs.cosmic-horizon.com) + +To contribute to documentation please ask for the contributor role in our [Discord](https://discord.cosmic-horizon.com) + +#### Auto-Generated Documentation + +- Protobuf documentation is auto-generated and served on [Buf Schema Registry](https://buf.build/qwoyn/QWOYN/docs). The documentation is auto-generated using the comments provided in the proto files. This documentation acts as the source of truth for the API of the application. +- Documentation for each feature is auto-generated and served on [docs.cosmic-horizon.com](https://docs.cosmic-horizon.com). The documentation is auto-generated using the feature files written in Gherkin Syntax. This documentation acts as the source of truth for the intended behavior of each feature. +- CLI documentation is auto-generated and served on [docs.cosmic-horizon.com](https://docs.cosmic-horizon.com). The documentation is auto-generated using [the cobra command properties](https://pkg.go.dev/github.com/spf13/cobra#Command). This documentation acts as the source of truth for the commands available when using the `qwoynd` binary. + +### Writing Specifications + +[ work in progress... check back soon ] \ No newline at end of file diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md new file mode 100644 index 0000000..e8c5b27 --- /dev/null +++ b/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. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..c584d7d --- /dev/null +++ b/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 security@cosmic-horizon.com.** + +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) diff --git a/startport-instructions.md b/startport-instructions.md deleted file mode 100644 index afc3d2c..0000000 --- a/startport-instructions.md +++ /dev/null @@ -1,56 +0,0 @@ -# Qwoyn - -**Qwoyn** is a blockchain built using Cosmos SDK and Tendermint and created with [Starport](https://starport.com). - -## Get started - -``` -starport chain serve -``` - -`serve` command installs dependencies, builds, initializes, and starts your blockchain in development. - -### Configure - -Your blockchain in development can be configured with `config.yml`. To learn more, see the [Starport docs](https://docs.starport.com). - -### Web Frontend - -Starport has scaffolded a Vue.js-based web app in the `vue` directory. Run the following commands to install dependencies and start the app: - -``` -cd vue -npm install -npm run serve -``` - -The frontend app is built using the `@starport/vue` and `@starport/vuex` packages. For details, see the [monorepo for Starport front-end development](https://github.com/tendermint/vue). - -## Release - -To release a new version of your blockchain, create and push a new tag with `v` prefix. A new draft release with the configured targets will be created. - -``` -git tag v0.1 -git push origin v0.1 -``` - -After a draft release is created, make your final changes from the release page and publish it. - -### Install - -To install the latest version of your blockchain node's binary, execute the following command on your machine: - -``` -curl https://get.starport.com/cosmic-horizon/QWOYN@latest! | sudo bash -``` - -`cosmic-horizon/QWOYN` should match the `username` and `repo_name` of the Github repository to which the source code was pushed. Learn more about [the install process](https://github.com/allinbits/starport-installer). - -## Learn more - -- [Starport](https://starport.com) -- [Tutorials](https://docs.starport.com/guide) -- [Starport docs](https://docs.starport.com) -- [Cosmos SDK docs](https://docs.cosmos.network) -- [Developer Chat](https://discord.gg/H6wGTY8sxw)