From bfe6695b222161e35fc29246f7b2887f20018342 Mon Sep 17 00:00:00 2001 From: Kenny Date: Sat, 28 Sep 2024 15:47:03 -0400 Subject: [PATCH] add contributing, changelog, security md files --- CHANGELOG.md | 49 +++++++++++++++++++++++++++++++++ CONTRIBUTING.md | 47 ++++++++++++++++++++++++++++++++ SECURITY.md | 72 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 168 insertions(+) create mode 100644 CHANGELOG.md create mode 100644 CONTRIBUTING.md create mode 100644 SECURITY.md diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..e551ab7 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,49 @@ + + +# Changelog + +All notable changes to this project will be documented in this file. + +The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), +and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html) for all versions `v1.0.0` and beyond (still considered experimental prior to v1.0.0). + +## [Unreleased] + +## v0.1.0 + +*Initial release.* + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..3e8d1f3 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,47 @@ +# Contribution Guidelines + +*Borrowed from Osmosis's [contribution guidelines](https://github.com/osmosis-labs/osmosis/blob/main/CONTRIBUTING.md)* + +Any contribution that you make to this repository will +be under the Apache 2 License, as dictated by that +[license](http://www.apache.org/licenses/LICENSE-2.0.html): + +~~~ +5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. +~~~ + +Contributors must sign-off each commit by adding a `Signed-off-by: ...` +line to commit messages to certify that they have the right to submit +the code they are contributing to the project according to the +[Developer Certificate of Origin (DCO)](https://developercertificate.org/). + +# General Style + +We follow a hexagonal/"ports and adapters" architecture. This means that the domain layer is decoupled from the implementation details of the adapters and the ports. This allows for a more modular and testable codebase. + +# General Philosophy + +Allora producer is meant to be used by any consumer of Allora chain events. These may include forecasters, who will use the events to inform their forecasting models. It may also include other services, indexing, cached RPC endpoint, or monitoring tools. However, the producer is not meant to directly support all possible consumers, but rather to provide a standardized way to parse and relay events on Allora chain. We focus on data production here, not data consumption. + +Thus, it's important to keep the general applicability of this repo in mind, and to avoid adding convenience methods or making the codebase more opinionated for specific consumers. + +# Standard Domain Event Format + +We have defined a standard format for domain events that are emitted by modules. This allows for a more consistent and predictable way to handle events in the codebase, and allows for easier parsing of events by consumers and maximally general event handlers. + +### Example + +```go +Message{ + ID: "0x" + hex.EncodeToString(hash[:]), + Type: msgType, + Name: name, + Timestamp: time.Now().UTC(), +} +``` diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..450b544 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,72 @@ +# Security Policy + +## Introduction + +Security researchers are essential in identifying vulnerabilities that may impact the Allora ecosystem. If you have discovered a security vulnerability in the Allora chain or any repository managed by Allora, we encourage you to notify us using one of the methods outlined below. + +### Guidelines for Responsible Vulnerability Testing and Reporting + +1. **Refrain from testing vulnerabilities on our publicly accessible environments**, including but not limited to: + - Allora mainnet + - any Allora-affiliated frontends e.g. allora.network, alloralabs.xyz + - Allora public testnets + - Allora testnet frontend + +2. **Avoid reporting security vulnerabilities through public channels, including GitHub issues** + +## Reporting Security Issues + +To privately report a security vulnerability, please choose one of the following options: + +### 1. Email + +Send your detailed vulnerability report to `security@alloralabs.xyz`. + +### 2. GitHub Private Vulnerability Reporting + +Utilize [GitHub's Private Vulnerability Reporting](https://github.com/allora-network/allora-chain/security/advisories/new) for confidential disclosure. + +## Submit Vulnerability Report + +When reporting a vulnerability through either method, please include the following details to aid in our assessment: + +- Type of vulnerability +- Description of the vulnerability +- Steps to reproduce the issue +- Impact of the issue +- Explanation of how an attacker could exploit it + +## Vulnerability Disclosure Process + +1. **Initial Report**: Submit the vulnerability via one of the above channels. +2. **Confirmation**: We will confirm receipt of your report within 48 hours. +3. **Assessment**: Our security team will evaluate the vulnerability and inform you of its severity and the estimated time frame for resolution. +4. **Resolution**: Once fixed, you will be contacted to verify the solution. +5. **Public Disclosure**: Details of the vulnerability may be publicly disclosed after ensuring it poses no further risk. + +During the vulnerability disclosure process, we ask security researchers to keep vulnerabilities and communications around vulnerability submissions private and confidential until a patch is developed. Should a security issue require a network upgrade, additional time may be needed to raise a governance proposal and complete the upgrade. + +During this time: + +- Avoid exploiting any vulnerabilities you discover. +- Demonstrate good faith by not disrupting or degrading Allora's services. + +## Severity Characterization + +| Severity | Description | +| ------------ | ----------------------------------------------------------------------- | +| **CRITICAL** | Immediate threat to critical systems (e.g., chain halts, funds at risk) | +| **HIGH** | Significant impact on major functionality | +| **MEDIUM** | Impacts minor features or exposes non-sensitive data | +| **LOW** | Minimal impact | + +## Bug Bounty + +Though we don't have an official bug bounty program, we generally offer rewards to security researchers who responsibly disclose vulnerabilities to us. Bounties are generally awarded for vulnerabilities classified as **high** or **critical** severity. Bounty amounts will be determined during the disclosure process, after the severity has been assessed. Please note that in order to collect a bounty, the reporter must go through a KYC process. + +> [!WARNING] +> Targeting our production environments will disqualify you from receiving any bounty. + +## Feedback on this Policy + +For recommendations on how to improve this policy, either submit a pull request or send an email to `security@allora.network`.