feat(tron): add TRON Full/Lite node runner blueprint#1
Conversation
|
/q review |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
I've reviewed the TRON node runner blueprint implementation. This is a well-structured addition that follows established patterns from other blockchain node runners in the repository.
Critical Issue Found (1)
- Security Vulnerability: Hardcoded untrusted IP address in
download-snapshot.shpresents a man-in-the-middle attack risk when downloading multi-TB snapshots over HTTP
Overall Assessment
The implementation demonstrates solid engineering with proper IAM policies, security group configurations, least-privilege access, IMDSv2, encryption, and cdk-nag compliance. The architecture adapts proven patterns from BSC and VeChain blueprints. Once the security issue is addressed, this will be ready to merge.
Recommendation: Address the security finding before merging.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| exit 0 | ||
| fi | ||
| # Official mainnet RocksDB source (America). Auto-discover the latest dated backup dir. | ||
| SNAP_HOST="http://35.197.17.205" |
There was a problem hiding this comment.
🛑 Security Vulnerability: Hardcoded untrusted IP address. The script downloads multi-TB data from a bare IP address (35.197.17.205) without HTTPS, enabling potential man-in-the-middle attacks or data tampering1. Add domain verification or use HTTPS with certificate validation.
Footnotes
-
CWE-300: Channel Accessible by Non-Endpoint - https://cwe.mitre.org/data/definitions/300.html ↩
There was a problem hiding this comment.
Review Summary
This PR adds a comprehensive TRON node runner blueprint with single-node, HA, and snapshot configurations. The infrastructure code follows AWS best practices with cdk-nag compliance and appropriate security group configurations. However, 8 critical security vulnerabilities and logic errors must be fixed before merge:
Critical Security Issues
- Unverified HTTP snapshot downloads - Downloading multi-GB database snapshots from HTTP IP address without integrity checks (supply chain attack vector)
- Unverified JAR downloads - Executing java-tron JAR from GitHub without checksum validation (code injection risk)
- Sudo privileges for service account - bcuser has unnecessary root access, violating least privilege
- Overly broad IAM CloudFormation policy - Can signal any stack in the account
- Missing systemd security hardening - No privilege restrictions on TRON service
Critical Logic Errors
- Missing S3 bucket environment variable - TRON_SNAPSHOT_S3_BUCKET not passed to download script, breaking S3 mode
- Fragile volume detection - Size-based matching could format root volume, causing data loss
- Incomplete pipeline error checking - Only checks s5cmd exit status, not tar/zstd failures
All issues have specific fixes provided. Address these critical defects before merging to prevent security incidents and operational failures.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| SNAP_HOST="http://35.197.17.205" | ||
| LATEST_DIR=$(curl -s --max-time 30 "$SNAP_HOST/" | grep -oE 'backup[0-9]{8}/' | sort -u | tail -1) | ||
| if [ -z "$LATEST_DIR" ]; then | ||
| echo "WARNING: could not auto-discover latest snapshot dir on $SNAP_HOST. Syncing from genesis." | ||
| exit 0 | ||
| fi | ||
| SNAPSHOT_URL="$SNAP_HOST/$LATEST_DIR$SNAP_FILE" |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading snapshots from an unvalidated HTTP endpoint without integrity verification. The script downloads multi-gigabyte database snapshots from ` (an IP address) over HTTP without checksum validation. This creates a supply chain attack vector where a malicious actor who compromises the snapshot source could inject malicious data into the blockchain database, potentially leading to data corruption or unauthorized access. Add checksum verification after download or use HTTPS with certificate validation.
| if [[ "$TRON_DOWNLOAD_SNAPSHOT" == "true" ]]; then | ||
| echo "Downloading TRON snapshot" | ||
| chmod +x /opt/download-snapshot.sh | ||
| su - bcuser -c "TRON_NODE_TYPE=$TRON_NODE_TYPE TRON_NETWORK=$TRON_NETWORK TRON_DB_ENGINE=$TRON_DB_ENGINE TRON_SNAPSHOTS_URI=$TRON_SNAPSHOTS_URI /opt/download-snapshot.sh" |
There was a problem hiding this comment.
🛑 Logic Error: Missing TRON_SNAPSHOT_S3_BUCKET environment variable in snapshot download script invocation. Line 215 passes TRON_NODE_TYPE, TRON_NETWORK, TRON_DB_ENGINE, and TRON_SNAPSHOTS_URI as environment variables to download-snapshot.sh, but does not pass TRON_SNAPSHOT_S3_BUCKET. This causes the S3 snapshot mode (TRON_SNAPSHOT_TYPE=s3) to fail because download-snapshot.sh checks for TRON_SNAPSHOT_S3_BUCKET at line 37 but the variable is never passed to the script's environment.
| su - bcuser -c "TRON_NODE_TYPE=$TRON_NODE_TYPE TRON_NETWORK=$TRON_NETWORK TRON_DB_ENGINE=$TRON_DB_ENGINE TRON_SNAPSHOTS_URI=$TRON_SNAPSHOTS_URI /opt/download-snapshot.sh" | |
| su - bcuser -c "TRON_NODE_TYPE=$TRON_NODE_TYPE TRON_NETWORK=$TRON_NETWORK TRON_DB_ENGINE=$TRON_DB_ENGINE TRON_SNAPSHOTS_URI=$TRON_SNAPSHOTS_URI TRON_SNAPSHOT_TYPE=$TRON_SNAPSHOT_TYPE TRON_SNAPSHOT_S3_BUCKET=$TRON_SNAPSHOT_S3_BUCKET /opt/download-snapshot.sh" |
| DATA_VOLUME_ID=/dev/$(lsblk -lnb | awk -v VOLUME_SIZE_BYTES="$DATA_VOLUME_SIZE" '{if ($4== VOLUME_SIZE_BYTES) {print $1}}') | ||
| mkfs -t xfs "$DATA_VOLUME_ID" | ||
| sleep 10 | ||
| DATA_VOLUME_UUID=$(lsblk -fn -o UUID "$DATA_VOLUME_ID") | ||
| DATA_VOLUME_FSTAB_CONF="UUID=$DATA_VOLUME_UUID /data xfs defaults 0 2" | ||
| echo "DATA_VOLUME_ID=$DATA_VOLUME_ID" | ||
| echo "$DATA_VOLUME_FSTAB_CONF" | tee -a /etc/fstab | ||
| mount -a |
There was a problem hiding this comment.
🛑 Logic Error: Volume detection using size matching is fragile and can incorrectly identify the root volume. Line 198 identifies the data volume by matching size alone, which will fail if the root volume happens to be the same size or if multiple volumes exist. The root volume could be mistakenly formatted, causing catastrophic data loss and preventing instance boot. Use a more reliable method like checking for NVMe device names, AWS volume tags, or device path patterns (e.g., /dev/nvme1n1 vs /dev/nvme0n1).
| FULLNODE_JAR_URL=$(curl -s https://api.github.com/repos/tronprotocol/java-tron/releases/latest | jq -r --arg n "$JAR_ASSET" '.assets[] | select(.name==$n) | .browser_download_url') | ||
| if [ -z "$FULLNODE_JAR_URL" ] || [ "$FULLNODE_JAR_URL" == "null" ]; then | ||
| echo "Could not resolve $JAR_ASSET asset URL, falling back to latest/download redirect" | ||
| FULLNODE_JAR_URL="https://github.com/tronprotocol/java-tron/releases/latest/download/$JAR_ASSET" | ||
| fi | ||
| echo "Downloading $JAR_ASSET from: $FULLNODE_JAR_URL" | ||
| wget -q -O FullNode.jar "$FULLNODE_JAR_URL" |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading and executing JAR file from GitHub without integrity verification. Lines 102-108 download the java-tron FullNode.jar from GitHub releases without verifying checksums or signatures. A compromised GitHub account or man-in-the-middle attack could inject malicious code into the JAR that would execute with full bcuser privileges. Download the corresponding checksum file from the release and verify the JAR's SHA256 hash before execution.1
Footnotes
-
CWE-494: Download of Code Without Integrity Check - https://cwe.mitre.org/data/definitions/494.html ↩
| tar -cf - -C /data output-directory | zstd -T0 | s5cmd pipe "s3://${TRON_SNAPSHOT_S3_BUCKET}/${S3_KEY}" | ||
| status=${PIPESTATUS[2]} | ||
|
|
||
| echo "$(date '+%F %T') Restarting tron" | ||
| systemctl start tron | ||
|
|
||
| if [ "$status" -eq 0 ]; then | ||
| echo "$(date '+%F %T') Snapshot upload complete." | ||
| else | ||
| echo "$(date '+%F %T') WARNING: snapshot upload failed (s5cmd status $status)." | ||
| fi |
There was a problem hiding this comment.
🛑 Logic Error: PIPESTATUS array index mismatch causes incorrect error detection. Line 31 checks ${PIPESTATUS[2]} but the pipeline has only 3 commands (tar|zstd|s5cmd), so the indices are 0,1,2 and PIPESTATUS[2] correctly checks s5cmd. However, if tar or zstd fails, the upload continues and may upload corrupted data. Check all pipeline components: (( ${PIPESTATUS[0]} != 0 || ${PIPESTATUS[1]} != 0 || ${PIPESTATUS[2]} != 0 )) to detect failures in tar, zstd, or s5cmd.
| tar -cf - -C /data output-directory | zstd -T0 | s5cmd pipe "s3://${TRON_SNAPSHOT_S3_BUCKET}/${S3_KEY}" | |
| status=${PIPESTATUS[2]} | |
| echo "$(date '+%F %T') Restarting tron" | |
| systemctl start tron | |
| if [ "$status" -eq 0 ]; then | |
| echo "$(date '+%F %T') Snapshot upload complete." | |
| else | |
| echo "$(date '+%F %T') WARNING: snapshot upload failed (s5cmd status $status)." | |
| fi | |
| tar -cf - -C /data output-directory | zstd -T0 | s5cmd pipe "" | |
| pipestatus=("${PIPESTATUS[@]}") | |
| echo "$(date '+%F %T') Restarting tron" | |
| systemctl start tron | |
| if [ "${pipestatus[0]}" -ne 0 ] || [ "${pipestatus[1]}" -ne 0 ] || [ "${pipestatus[2]}" -ne 0 ]; then | |
| echo "$(date '+%F %T') WARNING: snapshot upload failed (tar=${pipestatus[0]}, zstd=${pipestatus[1]}, s5cmd=${pipestatus[2]})." | |
| else | |
| echo "$(date '+%F %T') Snapshot upload complete." | |
| fi |
| instanceRole.addToPolicy(new iam.PolicyStatement({ | ||
| resources: ["*"], | ||
| actions: ["cloudformation:SignalResource"] | ||
| })); |
There was a problem hiding this comment.
🛑 Security Vulnerability: Overly broad IAM policy allows SignalResource on all CloudFormation stacks. Line 28 grants cloudformation:SignalResource on "*" resources, allowing the instance to signal any CloudFormation stack in the account, not just its own. An attacker gaining access to the instance could manipulate unrelated stack deployments. Restrict to the specific stack ARN pattern: arn:aws:cloudformation:${region}:${this.AWS_ACCOUNT_ID}:stack/tron-*/*.1
| instanceRole.addToPolicy(new iam.PolicyStatement({ | |
| resources: ["*"], | |
| actions: ["cloudformation:SignalResource"] | |
| })); | |
| instanceRole.addToPolicy(new iam.PolicyStatement({ | |
| resources: [`arn:aws:cloudformation:${region}:${this.AWS_ACCOUNT_ID}:stack/tron-*/*`], | |
| actions: ["cloudformation:SignalResource"] | |
| })); |
Footnotes
-
CWE-732: Incorrect Permission Assignment for Critical Resource - https://cwe.mitre.org/data/definitions/732.html ↩
| sudo bash -c 'cat > /etc/systemd/system/tron.service <<EOF | ||
| [Unit] | ||
| Description=TRON java-tron Node | ||
| After=network-online.target | ||
| [Service] | ||
| Type=simple | ||
| Restart=always | ||
| RestartSec=30 | ||
| User=bcuser | ||
| LimitNOFILE=1000000 | ||
| WorkingDirectory=/home/bcuser/tron | ||
| ExecStart=/home/bcuser/tron/start.sh | ||
| [Install] | ||
| WantedBy=multi-user.target | ||
| EOF' |
There was a problem hiding this comment.
🛑 Security Vulnerability: Missing systemd security hardening leaves the TRON service vulnerable. The systemd unit at lines 157-171 runs the TRON node with minimal security restrictions. A vulnerability in java-tron could be exploited to compromise the entire host. Add security directives: NoNewPrivileges=true, PrivateTmp=true, ProtectSystem=strict, ProtectHome=true, ReadWritePaths=/data, and RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX to limit the blast radius of potential exploits.1
Footnotes
-
CWE-250: Execution with Unnecessary Privileges - https://cwe.mitre.org/data/definitions/250.html ↩
| echo 'Adding bcuser user and group' | ||
| sudo groupadd -g 1002 bcuser | ||
| sudo useradd -u 1002 -g 1002 -m -s /bin/bash bcuser | ||
| sudo usermod -aG sudo bcuser |
There was a problem hiding this comment.
🛑 Security Vulnerability: Granting unnecessary sudo privileges to the blockchain service account. Line 87 adds bcuser to the sudo group, giving the account that runs the TRON node full root privileges. If the java-tron process is compromised through a vulnerability, an attacker gains immediate root access to the entire system. Remove sudo access as the TRON node doesn't require elevated privileges for normal operation.1
| echo 'Adding bcuser user and group' | |
| sudo groupadd -g 1002 bcuser | |
| sudo useradd -u 1002 -g 1002 -m -s /bin/bash bcuser | |
| sudo usermod -aG sudo bcuser | |
| echo 'Adding bcuser user and group' | |
| sudo groupadd -g 1002 bcuser | |
| sudo useradd -u 1002 -g 1002 -m -s /bin/bash bcuser |
Footnotes
-
CWE-269: Improper Privilege Management - https://cwe.mitre.org/data/definitions/269.html ↩
snese
force-pushed
the
feat/tron-node-runner
branch
from
bc28c24 to
29cf96a
Compare
|
/q review |
There was a problem hiding this comment.
Summary
This PR adds a comprehensive TRON node runner blueprint with single-node, HA, and snapshot configurations. The infrastructure code and CDK implementation follow good patterns from existing blueprints. However, 5 critical defects must be fixed before merge:
Critical Issues (Must Fix):
- Security Vulnerability: Multi-GB snapshot downloads over unencrypted HTTP from bare IP (35.197.17.205) enable MITM attacks
- Logic Error: Variable name mismatch (TRON_SNAPSHOTS_URL vs TRON_SNAPSHOTS_URI) breaks configuration override
- Logic Error: Suppressed wget errors prevent detection of JAR download failures, causing silent startup failures
- Logic Error: Suppressed wget errors for config.conf downloads cause cryptic startup failures
- Security Vulnerability: Missing TRON domains in URL allowlist blocks commits or provides no download validation
All issues have actionable fixes provided with code suggestions. The architecture is sound once these defects are corrected.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| # Integrity note: this is TRON's official public snapshot host but is plain HTTP from a bare IP, | ||
| # so it provides no transport integrity. Override with TRON_SNAPSHOTS_URI to use a trusted/HTTPS | ||
| # mirror. TRON does not currently publish a snapshot checksum; add verification here if one exists. | ||
| SNAP_HOST="http://35.197.17.205" |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading multi-gigabyte snapshots over unencrypted HTTP from a bare IP address (35.197.17.205) enables man-in-the-middle attacks that could inject malicious data into the blockchain node database. An attacker controlling network traffic could replace the snapshot with corrupted or malicious data, compromising the integrity of the entire node.
| SNAPSHOT_URL="$TRON_SNAPSHOTS_URI" | ||
| if [ -z "$SNAPSHOT_URL" ] || [ "$SNAPSHOT_URL" == "none" ]; then | ||
| if [ "$TRON_NETWORK" == "nile" ]; then | ||
| echo "WARNING: no default Nile RocksDB snapshot. Set TRON_SNAPSHOTS_URL or the node syncs from genesis." |
There was a problem hiding this comment.
🛑 Logic Error: Variable TRON_SNAPSHOTS_URL is checked in the warning message at line 66, but the actual environment variable being read is TRON_SNAPSHOTS_URI (line 63). This mismatch causes users to set the wrong variable name, preventing the override from working. The node will continue downloading from the insecure HTTP source even when users try to configure a secure alternative.
| echo "WARNING: no default Nile RocksDB snapshot. Set TRON_SNAPSHOTS_URL or the node syncs from genesis." | |
| echo "WARNING: no default Nile RocksDB snapshot. Set TRON_SNAPSHOTS_URI or the node syncs from genesis." |
| echo "Downloading $JAR_ASSET from: $FULLNODE_JAR_URL" | ||
| # Integrity: fetched over HTTPS from the official tronprotocol GitHub releases. java-tron does not | ||
| # currently publish per-asset checksums in its releases; add SHA256 verification here if/when it does. | ||
| wget -q -O FullNode.jar "$FULLNODE_JAR_URL" |
There was a problem hiding this comment.
🛑 Logic Error: The -q flag suppresses wget errors, preventing detection of download failures. If the java-tron JAR download fails silently (network error, GitHub API rate limit, invalid URL), the script continues with a corrupt or empty FullNode.jar file, causing the node service to fail at startup without clear error messaging. Remove -q to enable proper error handling.
| wget -q -O FullNode.jar "$FULLNODE_JAR_URL" | |
| wget -O FullNode.jar "$FULLNODE_JAR_URL" || { echo "ERROR: Failed to download FullNode.jar"; exit 1; } |
| wget -q -O config.conf https://raw.githubusercontent.com/tron-nile-testnet/nile-testnet/master/framework/src/main/resources/config-nile.conf | ||
| else | ||
| echo "Fetching mainnet config" | ||
| wget -q -O config.conf https://raw.githubusercontent.com/tronprotocol/java-tron/master/framework/src/main/resources/config.conf |
There was a problem hiding this comment.
🛑 Logic Error: Configuration file downloads use -q flag which suppresses all wget output including errors. If the config.conf download fails (network issue, GitHub outage, rate limit), an empty or corrupt file is created, causing java-tron to fail at startup with cryptic errors. The error checking must be added to catch download failures before the node service starts.
| wget -q -O config.conf https://raw.githubusercontent.com/tron-nile-testnet/nile-testnet/master/framework/src/main/resources/config-nile.conf | |
| else | |
| echo "Fetching mainnet config" | |
| wget -q -O config.conf https://raw.githubusercontent.com/tronprotocol/java-tron/master/framework/src/main/resources/config.conf | |
| wget -O config.conf || { echo "ERROR: Failed to download Nile config"; exit 1; } | |
| else | |
| echo "Fetching mainnet config" | |
| wget -O config.conf || { echo "ERROR: Failed to download mainnet config"; exit 1; } |
| TRUSTED_DOMAINS=( | ||
| "s3.amazonaws.com" | ||
| "awscli.amazonaws.com" | ||
| "yum.corretto.aws" |
There was a problem hiding this comment.
🛑 Security Vulnerability: The allowlist is missing required TRON-specific domains. The TRON blueprint downloads from (insecure HTTP snapshot host), api.trongrid.io, nile.trongrid.io (RPC endpoints), and GitHub repos (tronprotocol/java-tron, tron-nile-testnet/nile-testnet). Without these in the allowlist, either the pre-commit hook blocks commits or provides no validation against the insecure downloads. Add these entries:
TRUSTED_DOMAINS: "api.trongrid.io", "nile.trongrid.io"
TRUSTED_REPOS: "github.com/tronprotocol/java-tron"
TRUSTED_ORGS: "github.com/tron-nile-testnet"
Note: The HTTP snapshot host 35.197.17.205 should NOT be added to the allowlist as it poses a security risk.
Add a Node Runner Blueprint for TRON (java-tron) supporting single-node,
highly available (ASG + ALB), and snapshot-node deployments. Adapted from
the BSC blueprint with the VeChain node-type pattern, and aligned with the
ethereum/tezos S3 sync-node pattern for repeatable bootstrap.
- Default to AWS Graviton (ARM64): Amazon Corretto 17, G1GC (not CMS, which
is removed in JDK 17), and the FullNode-aarch64.jar release; ROCKSDB engine
(the generic FullNode.jar bundles an x86-only rocksdb native lib)
- Node types: Lite FullNode and FullNode via TRON_NODE_CONFIGURATION
- Networks: mainnet and Nile testnet
- Snapshot bootstrap via TRON_SNAPSHOT_TYPE: none | public | s3
- public: aria2c multi-connection (Lite, ~3x) or disk-safe streaming (Full),
pigz decompression, auto-discovery of the latest official backup dir
- s3: private per-account staging bucket populated by the snapshot node,
stored as multithreaded zstd and restored via s5cmd (transfer-bound)
- Security group: P2P 18888 (TCP/UDP) public; HTTP 8090 and gRPC 50051
restricted to the VPC; ALB health check on /wallet/getnowblock
- CloudWatch dashboard and sync checker (block height / blocks behind)
- cdk-nag clean with documented suppressions; unit tests for all four stacks
- README with Well-Architected 6-pillar checklist and architecture diagrams
snese
force-pushed
the
feat/tron-node-runner
branch
from
29cf96a to
7695bb1
Compare
|
Thanks for the review. Addressed in the latest commit (7695bb1): Fixed
Already addressed in an earlier commit (re-flagged)
Intentional / documented (not changing)
|
|
/q review |
There was a problem hiding this comment.
This PR adds a comprehensive TRON node runner blueprint with good security practices including IMDSv2, EBS encryption, SSM-only access, and least-privilege IAM policies. However, there are 5 critical issues that block merge:
Security Vulnerabilities (Must Fix):
- HTTP snapshot downloads without integrity verification expose to MITM attacks
- JAR file downloads from GitHub lack checksum verification before execution
- Configuration files downloaded without integrity checks could be compromised
Logic Errors (Must Fix):
4. Incorrect variable expansion syntax in Java heap size configuration will cause wrong JVM parameters
5. Echo statement uses wrong syntax and will display literal text instead of computed value
All identified issues have specific fixes provided. Address these critical defects before merge.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| SNAP_HOST="http://35.197.17.205" | ||
| LATEST_DIR=$(curl -s --max-time 30 "$SNAP_HOST/" | grep -oE 'backup[0-9]{8}/' | sort -u | tail -1) | ||
| if [ -z "$LATEST_DIR" ]; then | ||
| echo "WARNING: could not auto-discover latest snapshot dir on $SNAP_HOST. Syncing from genesis." | ||
| exit 0 | ||
| fi | ||
| SNAPSHOT_URL="$SNAP_HOST/$LATEST_DIR$SNAP_FILE" |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading snapshots over unencrypted HTTP from a bare IP address exposes the system to man-in-the-middle attacks1. An attacker could replace the snapshot with a malicious database containing invalid blockchain data or exploits. Replace with HTTPS-enabled mirror or implement cryptographic verification of downloaded snapshots.
Footnotes
-
CWE-311: Missing Encryption of Sensitive Data - https://cwe.mitre.org/data/definitions/311.html ↩
| FULLNODE_JAR_URL=$(curl -s https://api.github.com/repos/tronprotocol/java-tron/releases/latest | jq -r --arg n "$JAR_ASSET" '.assets[] | select(.name==$n) | .browser_download_url') | ||
| if [ -z "$FULLNODE_JAR_URL" ] || [ "$FULLNODE_JAR_URL" == "null" ]; then | ||
| echo "Could not resolve $JAR_ASSET asset URL, falling back to latest/download redirect" | ||
| FULLNODE_JAR_URL="https://github.com/tronprotocol/java-tron/releases/latest/download/$JAR_ASSET" | ||
| fi | ||
| echo "Downloading $JAR_ASSET from: $FULLNODE_JAR_URL" | ||
| # Integrity: fetched over HTTPS from the official tronprotocol GitHub releases. java-tron does not | ||
| # currently publish per-asset checksums in its releases; add SHA256 verification here if/when it does. | ||
| wget -q -O FullNode.jar "$FULLNODE_JAR_URL" || { echo "ERROR: failed to download FullNode.jar from $FULLNODE_JAR_URL"; exit 1; } |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading executable JAR files from GitHub without checksum verification allows potential code execution from compromised releases1. If the GitHub release or API is compromised, malicious code could be executed with bcuser privileges. Add SHA256 checksum verification before executing the JAR file.
Footnotes
-
CWE-494: Download of Code Without Integrity Check - https://cwe.mitre.org/data/definitions/494.html ↩
| if [ "$TRON_NETWORK" == "nile" ]; then | ||
| echo "Fetching Nile testnet config" | ||
| wget -q -O config.conf https://raw.githubusercontent.com/tron-nile-testnet/nile-testnet/master/framework/src/main/resources/config-nile.conf || { echo "ERROR: failed to download Nile config"; exit 1; } | ||
| else | ||
| echo "Fetching mainnet config" | ||
| wget -q -O config.conf https://raw.githubusercontent.com/tronprotocol/java-tron/master/framework/src/main/resources/config.conf || { echo "ERROR: failed to download mainnet config"; exit 1; } | ||
| fi |
There was a problem hiding this comment.
🛑 Security Vulnerability: Downloading configuration files over HTTPS but without integrity verification could allow compromised configurations to be loaded1. A compromised config could redirect the node to malicious peers or alter critical security settings. Verify configuration file checksums or signatures before use.
Footnotes
-
CWE-494: Download of Code Without Integrity Check - https://cwe.mitre.org/data/definitions/494.html ↩
| MEM_TOTAL_KB=$(grep MemTotal /proc/meminfo | awk '{print $2}') | ||
| XMX_GB=$(( MEM_TOTAL_KB * 80 / 100 / 1024 / 1024 )) | ||
| if [ "$XMX_GB" -lt 4 ]; then XMX_GB=4; fi | ||
| echo "Setting -Xmx${!XMX_GB}g" |
There was a problem hiding this comment.
🛑 Logic Error: Echo statement uses incorrect variable expansion syntax with ! indirection that will print wrong output. The message will show "${!XMX_GB}g" literally instead of the computed heap size value. Replace with correct syntax to display the actual heap size value.
| echo "Setting -Xmx${!XMX_GB}g" | |
| echo "Setting -Xmx${XMX_GB}g" |
| sudo bash -c "cat > /home/bcuser/tron/start.sh <<EOF | ||
| #!/bin/bash | ||
| cd /home/bcuser/tron | ||
| exec java -Xmx${!XMX_GB}g $GC_OPTS -jar /home/bcuser/tron/FullNode.jar -c /home/bcuser/tron/config.conf -d /data/output-directory |
There was a problem hiding this comment.
🛑 Logic Error: Variable expansion in heredoc uses incorrect syntax that will print literal text "${!XMX_GB}g" instead of the computed heap size value. The ! indirection operator doesn't work in heredocs. Change to \${XMX_GB}g to properly escape and expand the variable value in the generated script.
| exec java -Xmx${!XMX_GB}g $GC_OPTS -jar /home/bcuser/tron/FullNode.jar -c /home/bcuser/tron/config.conf -d /data/output-directory | |
| exec java -Xmx${XMX_GB}g $GC_OPTS -jar /home/bcuser/tron/FullNode.jar -c /home/bcuser/tron/config.conf -d /data/output-directory |
1 participant
Fork-side review PR for Amazon Q Developer, mirroring upstream PR aws-samples#252 (same branch, so fixes here propagate to the upstream PR).
Adds the TRON (java-tron) node runner blueprint: single-node, HA (ASG + internal ALB), and an S3 snapshot-staging node. Adapted from BSC + VeChain node-type + ethereum/tezos S3 sync-node patterns.
Single commit. Upstream CI is green.