Compare commits

..
Author SHA1 Message Date
Michael Shaw fdfe6ca285 new json util test, turning off codecov fails CI, and gitignore for test artifacts 2023-01-30 16:08:31 -05:00
Michael Shaw a1ad1e1d35 Cleanup for whitespace and require.NoError in test 2023-01-27 15:22:34 -05:00
Michael Shaw ff74a447fe turn codecov back to fail on error true to avoid invisible failure. 2023-01-27 13:31:30 -05:00
Michael Shaw 0e13bf7702 disable fail_ci on codecov error... it is unstable 2023-01-27 13:13:50 -05:00
Michael Shaw f8889d0225 sleep and docker logs... appears endpoint is not coming up maybe? 2023-01-27 11:06:55 -05:00
Michael Shaw c80f690c5d revert ListenAndServe 2023-01-27 10:48:00 -05:00
Michael Shaw 9719b51a12 manual service check in laconicd container for diagnostic 2023-01-27 10:10:05 -05:00
Michael Shaw fa948ec9c2 host mode breaks name resolution of containers 2023-01-26 18:44:32 -05:00
Michael Shaw fb29cc26b2 try host mode network 2023-01-26 17:58:01 -05:00
Michael Shaw 07435d0597 trying localhost 2023-01-26 16:59:27 -05:00
Michael Shaw ec4f8d386d listen on 0.0.0.0 specfically 2023-01-26 16:35:42 -05:00
Michael Shaw 87e873dc18 docker network inspect for diagnostic missing arg 2023-01-26 15:09:36 -05:00
Michael Shaw 4867f2a362 docker network inspect for diagnostic 2023-01-26 14:38:18 -05:00
Michael Shaw 2be800f0bb checkout is done from inside of container, rather than copied in from filesystem. checking out dev branch for now 2023-01-26 12:38:26 -05:00
Michael Shaw 6ac975e213 use feature branch for laconic-sdk... UNDO THIS LATER 2023-01-26 10:41:54 -05:00
Michael Shaw 8973a0fbf3 missing curl for health check 2023-01-25 18:19:48 -05:00
Michael Shaw 357f5e8af2 try curl (retval 0) instead of wget (retval 8) for 404 that is returned 2023-01-25 17:35:14 -05:00
Michael Shaw 25d1577ce4 utils/json test for comparing known, but deprecated method to new implementation 2023-01-25 16:52:45 -05:00
Michael Shaw cac9fe327c golang linting is really picky 2023-01-25 16:52:45 -05:00
Michael Shaw 9261699745 unchecked error complaint from linter 2023-01-25 16:52:45 -05:00
Michael Shaw 15db2d3849 missing unmarshalling of content bytes before encoding and generation of CID 2023-01-25 16:52:45 -05:00
Michael Shaw 6c597101ea start built containers 2023-01-24 13:48:55 -05:00
Michael Shaw 90943bf1e6 ./ missing 2023-01-24 13:27:11 -05:00
Michael Shaw 512136400d checkout not preserved between actions 2023-01-24 12:37:28 -05:00
Michael Shaw c0662cb5f1 diagnostic env step does not support cwd 2023-01-24 12:32:54 -05:00
Michael Shaw c73dc0d92a diagnostic env step 2023-01-24 12:24:34 -05:00
Michael Shaw 8f20f25e43 diagnostic env step 2023-01-24 12:17:25 -05:00
Michael Shaw 08e369aa64 - -> _ 2023-01-24 11:56:53 -05:00
Michael Shaw 40a78c66bf first pass use tests/sdk-tests/run-tests.sh in github action 2023-01-24 10:38:38 -05:00
8 changed files with 79 additions and 142 deletions
+1 -24
View File
@@ -103,30 +103,7 @@ jobs:
- name: run-tests.sh
working-directory: tests/sdk_tests
run: ./run-tests.sh
- name: reset containers for auction tests
working-directory: tests/sdk_tests
if: always()
run: docker compose down
- name: start auction containers
working-directory: tests/sdk_tests
run: docker compose -f docker-compose-auctions.yml up -d
- name: run-acution-tests.sh
working-directory: tests/sdk_tests
run: ./run-auction-tests.sh
- name: reset containers for nameservice tests
working-directory: tests/sdk_tests
if: always()
run: docker compose -f docker-compose-auctions.yml down
- name: start auction containers
working-directory: tests/sdk_tests
run: docker compose -f docker-compose-nameservice.yml up -d
- name: run-nameservice-expiry-tests.sh
working-directory: tests/sdk_tests
run: ./run-nameservice-expiry-tests.sh
- name: reset containers for nameservice tests
working-directory: tests/sdk_tests
if: always()
run: docker compose -f docker-compose-nameservice.yml down
# integration_tests:
# runs-on: ubuntu-latest
+62
View File
@@ -0,0 +1,62 @@
# Security
As part of our vulnerability disclosure policy, we operate a security vulnerability program through [Immunefi](https://immunefi.com/). This document serves as a complementary guideline for reporting vulnerabilities and how the disclosure process is managed. Please refer to the official Evmos [bug bounty program](https://immunefi.com/bounty/evmos/) for up-to-date information.
## Guidelines
We require that all researchers:
- Use the Evmos [bug bounty program](https://immunefi.com/bounty/evmos/) on Immunefi to disclose all vulnerabilities, and avoid posting vulnerability information in public places, including GitHub, Discord, Telegram, Twitter or other non-private channels.
- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data.
- Keep any information about vulnerabilities that youve discovered confidential between yourself and the engineering team until the issue has been resolved and disclosed
- Avoid posting personally identifiable information, privately or publicly
If you follow these guidelines when reporting an issue to us, we commit to:
- Not pursue or support any legal action related to your research on this vulnerability
- Work with you to understand, resolve and ultimately disclose the issue in a timely fashion
## Disclosure Process
Evmos uses the following disclosure process:
1. Once a security report is received via the Immunefi Bug Bounty program, the team works to verify the issue and confirm its severity level using [CVSS](https://nvd.nist.gov/vuln-metrics/cvss) or [Immunefis Vulnerability Severity Classification System v2.2](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-2/).
1. Two people from the affected project will review, replicate and acknowledge the report within 48-96 hours of the alert according to the table below:
| Security Level | Hours to First Response (ACK) from Escalation |
| -------------------- | --------------------------------------------- |
| Critical | 48 |
| High | 96 |
| Medium | 96 |
| Low or Informational | 96 |
| None | 96 |
2. If the report is not applicable or reproducible, the Security Lead (or Security Secondary) will revert to the reporter to request more info or close the report.
3. The report is confirmed by the Security Lead to the reporter.
2. The team determines the vulnerabilitys potential impact on Evmos.
1. Vulnerabilities with `Informational` and `Low` categorization will result in creating a public issue.
2. Vulnerabilities with `Medium` categorization will result in the creation of an internal ticket and patch of the code.
3. Vulnerabilities with `High` or `Critical` will result in the [creation of a new Security Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory)
Once the vulnerability severity is defined, the following steps apply:
- For `High` and `Critical`:
1. Patches are prepared for supported releases of Evmos in a [temporary private fork](https://docs.github.com/en/code-security/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) of the repository.
2. Only relevant parties will be notified about an upcoming upgrade. These being validators, the core developer team, and users directly affected by the vulnerability.
3. 24 hours following this notification, relevant releases with the patch will be made public.
4. The nodes and validators update their Evmos and Ethermint dependencies to use these releases.
5. A week (or less) after the security vulnerability has been patched on Evmos, we will disclose that the mentioned release contained a security fix.
6. After an additional 2 weeks, we will publish a public announcement of the vulnerability. We also publish a security Advisory on GitHub and publish a [CVE](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)
- For `Informational` , `Low` and `Medium` severities:
1. `Medium` and `Low` severity bug reports are included in a public issue and will be incorporated in the current sprint and patched in the next release. `Informational` reports are additionally categorized as with low or medium priority and might not be included in the next release.
2. One week after the releases go out, we will publish a post with further details on the vulnerability as well as our response to it.
This process can take some time. Every effort will be made to handle the bug in as timely a manner as possible, however, it's important that we follow the process described above to ensure that disclosures are handled consistently and to keep Ethermint and its downstream dependent projects, including but not limited to Evmos, as secure as possible.
### Payment Process
The payment process will be executed according to Evmoss Immunefi Bug Bounty program Rules.
### Contact
The Evmos Security Team is constantly being monitored. If you need to reach out to the team directly, please reach out via email: [security@evmos.org](mailto:security@evmos.org)
+15 -24
View File
@@ -1,4 +1,4 @@
# Validator Guide for laconic_81337-6 Testnet
# Validator Guide for laconic_81337-5 Testnet
## Hardware Prerequisites
@@ -48,8 +48,8 @@ sudo apt install git curl build-essential make jq -y
# Remove any existing installation of `go`
sudo rm -rf /usr/local/go
# Install Go version 1.19.7
curl https://dl.google.com/go/go1.19.7.linux-amd64.tar.gz | sudo tar -C/usr/local -zxvf -
# Install Go version 1.18.8
curl https://dl.google.com/go/go1.18.8.linux-amd64.tar.gz | sudo tar -C/usr/local -zxvf -
# Update env variables to include go
cat <<'EOF' >>$HOME/.profile
@@ -67,7 +67,7 @@ Check the version of go installed
```sh
go version
# Should return something like: go version go1.19.7 linux/amd64
# Should return something like: go version go1.17.2 linux/amd64
```
---
@@ -80,17 +80,16 @@ cd laconicd
# Checkout main branch
git fetch --all
git checkout v0.8.0
git checkout v0.6.0
# Build and install laconic
make VERSION=v0.8.0 install
make install
```
Verify your installation
```sh
laconicd version --long
```
On running the above command, you should see a similar response like this. Make sure that the _version_ and _commit
@@ -123,13 +122,13 @@ Make sure the directory `~/.laconicd` does not exist or is empty
>In order to run the below commands in a docker container:
>```sh
>docker run -ti -v ~/.laconicd:/root/.laconicd \
>git.vdb.to/cerc-io/laconicd/laconicd:v0.8.0 /bin/sh
>git.vdb.to/cerc-io/laconicd/laconicd:v0.6.0 /bin/sh
>```
---
```sh
# Initialize the validator node
laconicd init <your-node-moniker> --chain-id laconic_81337-6
laconicd init <your-node-moniker> --chain-id laconic_81337-5
```
Running the above commands will initialize the validator node with default configuration. The config files will be saved in the default location (`~/.laconicd/config`).
@@ -169,7 +168,7 @@ Create Your `gentx` transaction file
```sh
laconicd gentx <key-name> 12900000000000000000000achk \
--pubkey=$(laconicd tendermint show-validator) \
--chain-id="laconic_81337-6" \
--chain-id="laconic_81337-5" \
--moniker="<your-moniker-name>" \
--website="<your-validator-website>" \
--details="<your-validator-description>" \
@@ -199,10 +198,10 @@ Submit your `gentx` file to the [https://github.com/cerc-io/laconic-testnet](htt
To submit the gentx file, follow the below process:
- Fork the [https://github.com/cerc-io/laconic-testnet](https://github.com/cerc-io/laconic-testnet) repository
- Upload your gentx file in the `laconic_81337-6/config/gentxs` folder
- Upload your gentx file in the `laconic_81337-5/config/gentxs` folder
- Submit Pull Request to [https://github.com/cerc-io/laconic-testnet](https://github.com/cerc-io/laconic-testnet) with name `ADD <your-moniker> gentx`
The genesis file will be published in the `laconic_81337-6/config/` folder within the [https://github.com/cerc-io/laconic-testnet](https://github.com/cerc-io/laconic-testnet) repository.
The genesis file will be published in the `laconic_81337-5/config/` folder within the [https://github.com/cerc-io/laconic-testnet](https://github.com/cerc-io/laconic-testnet) repository.
# CONTINUE WITH BELOW STEPS ONLY AFTER GENESIS FILE HAS BEEN PUBLISHED
@@ -272,33 +271,25 @@ journalctl -f -u laconicd
In this example the Tendermint RPC and Prometheus metrics ports are exposed only to localhost. You may want to change 127.0.0.1 to private or public network interface of your host if you need to access these ports remotely.
```sh
docker create \
--name laconic-testnet-6 \
--restart always \
-v ~/.laconicd:/root/.laconicd \
-p 26656:26656 \
-p 127.0.0.1:26657:26657 \
-p 127.0.0.1:26660:26660 \
git.vdb.to/cerc-io/laconicd/laconicd:v0.8.0 \
laconicd start --gql-playground --gql-server --log_level=warn
docker create --name laconic-testnet-5 -v ~/.laconicd:/root/.laconicd -p 26656:26656 -p 127.0.0.1:26657:26657 -p 127.0.0.1:26660:26660 git.vdb.to/cerc-io/laconicd/laconicd:v0.6.0 laconicd start --gql-playground --gql-server --log_level=warn
```
### Run validator node
```sh
docker start laconic-testnet-6
docker start laconic-testnet-5
```
### Check validator node logs
```sh
docker logs laconic-testnet-6
docker logs laconic-testnet-5
```
### Run shell inside docker container
```sh
docker exec -ti laconic-testnet-6 /bin/sh
docker exec -ti laconic-testnet-5 /bin/sh
```
---
## Helpful commands
+1
View File
@@ -47,6 +47,7 @@ WORKDIR /app
RUN \
git clone https://github.com/cerc-io/laconic-sdk.git \
&& cd laconic-sdk \
&& git checkout jest_timeout \
&& yarn install
WORKDIR /app/laconic-sdk
@@ -1,31 +0,0 @@
services:
laconicd:
restart: unless-stopped
image: cerc-io/laconicd:local-test
environment:
- TEST_AUCTION_ENABLED=true
command: ["sh", "/docker-entrypoint-scripts.d/create-fixturenet.sh"]
volumes:
- ../../init.sh:/docker-entrypoint-scripts.d/create-fixturenet.sh
healthcheck:
test: ["CMD", "curl", "-v", "http://127.0.0.1:6060"]
interval: 1s
timeout: 5s
retries: 30
ports:
- "6060"
- "26657"
- "26656"
- "9473"
- "8545"
- "8546"
- "9090"
- "9091"
- "1317"
sdk-test-runner:
image: cerc-io/laconic-sdk-tester:local-test
depends_on:
laconicd:
condition: service_healthy
command: tail -F /dev/null
@@ -1,31 +0,0 @@
services:
laconicd:
restart: unless-stopped
image: cerc-io/laconicd:local-test
environment:
- TEST_REGISTRY_EXPIRY=true
command: ["sh", "/docker-entrypoint-scripts.d/create-fixturenet.sh"]
volumes:
- ../../init.sh:/docker-entrypoint-scripts.d/create-fixturenet.sh
healthcheck:
test: ["CMD", "curl", "-v", "http://127.0.0.1:6060"]
interval: 1s
timeout: 5s
retries: 30
ports:
- "6060"
- "26657"
- "26656"
- "9473"
- "8545"
- "8546"
- "9090"
- "9091"
- "1317"
sdk-test-runner:
image: cerc-io/laconic-sdk-tester:local-test
depends_on:
laconicd:
condition: service_healthy
command: tail -F /dev/null
-16
View File
@@ -1,16 +0,0 @@
#!/usr/bin/env bash
if [ -n "$CERC_SCRIPT_DEBUG" ]; then
set -x
fi
# Get the key from laconicd
laconicd_key=$( docker compose exec laconicd echo y | docker compose exec laconicd laconicd keys export mykey --unarmored-hex --unsafe )
# Set parameters for the test suite
cosmos_chain_id=laconic_9000-1
laconicd_rest_endpoint=http://laconicd:1317
laconicd_gql_endpoint=http://laconicd:9473/api
# Run tests
docker network inspect sdk_tests_default
sleep 30s
docker logs sdk_tests-laconicd-1
docker compose exec sdk-test-runner sh -c "COSMOS_CHAIN_ID=${cosmos_chain_id} LACONICD_REST_ENDPOINT=${laconicd_rest_endpoint} LACONICD_GQL_ENDPOINT=${laconicd_gql_endpoint} PRIVATE_KEY=${laconicd_key} yarn test:auctions"
@@ -1,16 +0,0 @@
#!/usr/bin/env bash
if [ -n "$CERC_SCRIPT_DEBUG" ]; then
set -x
fi
# Get the key from laconicd
laconicd_key=$( docker compose exec laconicd echo y | docker compose exec laconicd laconicd keys export mykey --unarmored-hex --unsafe )
# Set parameters for the test suite
cosmos_chain_id=laconic_9000-1
laconicd_rest_endpoint=http://laconicd:1317
laconicd_gql_endpoint=http://laconicd:9473/api
# Run tests
docker network inspect sdk_tests_default
sleep 30s
docker logs sdk_tests-laconicd-1
docker compose exec sdk-test-runner sh -c "COSMOS_CHAIN_ID=${cosmos_chain_id} LACONICD_REST_ENDPOINT=${laconicd_rest_endpoint} LACONICD_GQL_ENDPOINT=${laconicd_gql_endpoint} PRIVATE_KEY=${laconicd_key} yarn test:nameservice-expiry"