-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
120 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
<!-- | ||
Guiding Principles: | ||
Changelogs are for humans, not machines. | ||
There should be an entry for every single version. | ||
The same types of changes should be grouped. | ||
Versions and sections should be linkable. | ||
The latest version comes first. | ||
The release date of each version is displayed. | ||
Mention whether you follow Semantic Versioning. | ||
Usage: | ||
Change log entries are to be added to the Unreleased section under the | ||
appropriate stanza (see below). Each entry should ideally include a tag and | ||
the Github issue reference in the following format: | ||
* (<tag>) \#<issue-number> message | ||
The issue numbers will later be link-ified during the release process so you do | ||
not have to worry about including a link manually, but you can if you wish. | ||
Types of changes (Stanzas): | ||
"Features" for new features. | ||
"Improvements" for changes in existing functionality. | ||
"Deprecated" for soon-to-be removed features. | ||
"Bug Fixes" for any bug fixes. | ||
"Client Breaking" for breaking Protobuf, gRPC and REST routes used by end-users. | ||
"CLI Breaking" for breaking CLI commands. | ||
"API Breaking" for breaking exported APIs used by developers building on SDK. | ||
"State Machine Breaking" for any changes that result in a different AppState given same genesisState and txList. | ||
Ref: https://keepachangelog.com/en/1.0.0/ | ||
--> | ||
|
||
# Changelog | ||
|
||
<!-- EXAMPLES: | ||
## v5.7.1 & v5.7.2 | ||
sei-chain | ||
* [#1779](https://github.com/sei-protocol/sei-chain/pull/1779) Fix subscribe logs empty params crash | ||
* [#1783](https://github.com/sei-protocol/sei-chain/pull/1783) Add meaningful message for eth_call balance override overflow | ||
* [#1783](https://github.com/sei-protocol/sei-chain/pull/1784) Fix log index on synthetic receipt | ||
* [#1775](https://github.com/sei-protocol/sei-chain/pull/1775) Disallow sending to direct cast addr after association | ||
sei-wasmd | ||
* [60](https://github.com/sei-protocol/sei-wasmd/pull/60) Query penalty fixes | ||
sei-tendermint | ||
* [#237](https://github.com/sei-protocol/sei-tendermint/pull/237) Add metrics for total txs bytes in mempool | ||
## v5.7.0 | ||
sei-chain | ||
* [#1731](https://github.com/sei-protocol/sei-chain/pull/1731) Remove 1-hop limit | ||
* [#1663](https://github.com/sei-protocol/sei-chain/pull/1663) Retain pointer address on upgrade --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 `[email protected]`. | ||
|
||
### 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 `[email protected]`. |