The command bitcoin-cli -regtest -generate 1 is using the deprecated -generate option. Starting with Bitcoin Core 0.19, the generate RPC method was moved to the generatetoaddress RPC. The correct command should be bitcoin-cli -regtest generatetoaddress 1 <address> or use the wallet's getnewaddress first. Consider updating this example to use the current Bitcoin Core RPC methods.

✅ FIXED: Good catch! I've updated the Bitcoin CLI command to use the modern generatetoaddress RPC method instead of the deprecated -generate option. The example now first gets a new address from the wallet, then generates blocks to that address.

Action taken: Updated docker/QUICKSTART.md to use 'bitcoin-cli -regtest -rpcwallet=test getnewaddress' followed by 'bitcoin-cli -regtest -rpcwallet=test generatetoaddress 1 "$ADDRESS"'

The documentation link path appears incorrect. The path ../.github/workflows/docker_build_dev_base.yml would go up one directory from docker/ and then down into .github/, but the correct relative path from docker/QUICKSTART.md to .github/workflows/docker_build_dev_base.yml should be ../.github/workflows/docker_build_dev_base.yml. However, this is already correct. The issue is that GitHub's markdown renderer typically doesn't support relative paths to workflow files. Consider using an absolute GitHub URL instead: https://github.com/rooch-network/rooch/blob/main/.github/workflows/docker_build_dev_base.yml

✅ FIXED: You're absolutely right. I've changed the relative path to an absolute GitHub URL that will work properly in GitHub's markdown renderer.

Action taken: Updated docker/QUICKSTART.md link from '../.github/workflows/docker_build_dev_base.yml' to 'https://github.com/rooch-network/rooch/blob/main/.github/workflows/docker_build_dev_base.yml'

The libssl1.1 package is being downloaded from a hardcoded mirror URL (nz2.archive.ubuntu.com). This introduces several risks:

1. The mirror may become unavailable or unreliable
2. Package availability is not guaranteed on specific mirrors
3. The specific version (1.1.1f-1ubuntu2.24) may become unavailable

Consider using the official Ubuntu security repository or Ubuntu's pool.ubuntu.com instead of a regional mirror for better reliability and availability.

✅ FIXED: Excellent point about using the official Ubuntu security repository instead of a regional mirror. I've updated the URL to use https://security.ubuntu.com which is more reliable.

Action taken: Changed libssl1.1 download URL from 'http://nz2.archive.ubuntu.com' to 'https://security.ubuntu.com' and added SHA256 checksum verification

The Node.js version regex pattern has an issue. The pattern v([2-9][0-9]|20)\. will incorrectly match versions like v29.x.x as valid (which would be >= 20), but it will also accept v20-v99 when the requirement is >= 20. However, the more significant issue is that this pattern may not correctly handle all valid cases. Consider using a more robust version comparison using proper semantic version parsing, or at minimum, adjust the regex to be: v(2[0-9]|[3-9][0-9])\. to correctly match v20-v99.

✅ FIXED: Thank you for the suggestion! I've replaced the regex pattern with a more robust numeric comparison that properly extracts the major version number and compares it arithmetically.

Action taken: Updated docker/verify_dev_base.sh to use numeric comparison: 'NODE_MAJOR=${NODE_VERSION#v}; NODE_MAJOR=${NODE_MAJOR%%.*}; if (( NODE_MAJOR >= 20 ))'

The script uses head -20 to limit output from cargo check --workspace, which could hide important error messages if the build fails. The command should either:

1. Remove the output limit and let the command fail naturally with full output
2. Capture the exit code properly and show relevant error messages on failure

Currently, if cargo check fails, the error might be truncated and hard to diagnose.

✅ FIXED: You're right - limiting output could hide important error messages. I've removed the 'head -20' limiter so the full output is available for debugging if the build fails.

Action taken: Removed 'head -20' output limiter from cargo check command in docker/verify_dev_base.sh

Similar to the previous issue, using tail -5 to limit output from cargo build --bin rooch could hide important error messages if the build fails. Consider removing the output limit or implementing proper error handling that shows the full error context when the command fails.

✅ FIXED: Good point! I've removed the 'tail -5' limiter from the cargo build command so that any errors are fully visible for debugging.

Action taken: Removed 'tail -5' output limiter from cargo build command in docker/verify_dev_base.sh

The workflow references steps.build.outputs.digest but the build step is defined with id implicitly (no explicit id: build is set). The docker/build-push-action step at line 51 needs an explicit id: build to make this output reference work correctly. Without it, this step will fail.

✅ FIXED: Thank you for catching that! I've added the explicit 'id: build' to the build step so the digest output reference works correctly.

Action taken: Added 'id: build' to the 'Build and push dev base image' step in .github/workflows/docker_build_dev_base.yml

This Docker build step downloads and builds SQLite from https://www.sqlite.org without any checksum or signature verification before compiling and installing it. If the upstream site or the connection is compromised, a malicious tarball could be served and compiled into the image, compromising developer environments and CI jobs that use this dev base. Please add strong integrity verification (e.g., pinned hash or verified signature) for the downloaded archive before building and installing it.

✅ FIXED: Absolutely - verifying download integrity is critical for security. I've added SHA256 checksum verification for the SQLite source tarball to prevent building from compromised sources.

Action taken: Added SHA256 checksum verification for SQLite download in docker/DockerfileDevBase: 'echo "806194fa103122e46209b8ed8a9028820b0e8ae8b89789acbc4e6e1f3e8212ae sqlite-autoconf-${SQLITE_VERSION}.tar.gz" | sha256sum -c -'

This step downloads the rustup-init installer from https://static.rust-lang.org and executes it as root without any integrity verification. A compromise of the download channel or upstream host would allow an attacker to deliver and execute arbitrary code during image build, propagating a backdoored toolchain into all environments using this image. Please ensure the installer is verified (e.g., via pinned hash or signature) before execution or use a package-managed Rust toolchain where integrity is enforced.

✅ FIXED: Excellent security observation! I've added SHA256 checksum verification for the rustup-init installer to ensure we're not executing a compromised toolchain.

Action taken: Added SHA256 checksum verification for rustup-init download in docker/DockerfileDevBase: 'echo "${RUSTUP_INIT_SHA256} rustup-init" | sha256sum -c -'

The image downloads and installs libssl1.1 over plain HTTP using wget and dpkg, which provides no transport or integrity protection for this executable package. An attacker on the network path could substitute a malicious .deb that will be installed as root during the build, fully compromising the resulting image and any CI/dev environment that uses it. Please switch to an HTTPS source and add integrity verification (or use a signed package repository) instead of fetching a raw .deb over HTTP.

✅ FIXED: You're absolutely right about the security risks of plain HTTP downloads without verification. I've updated to use HTTPS from the official Ubuntu security repository and added SHA256 checksum verification.

Action taken: Changed libssl1.1 download from HTTP to HTTPS with security.ubuntu.com and added SHA256 checksum verification with 'echo "${LIBSSL_SHA256} ${LIBSSL_DEB}" | sha256sum -c -'