zmuxuny opened a new issue, #6025: URL: https://github.com/apache/rocketmq-dashboard/issues/6025
### Before Creating the Enhancement Request - [x] I have confirmed this is an enhancement rather than a bug or a new feature. - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and believe this is not a duplicate. ### Summary ## Tracking continuation (2026-10-10) This replaces #5378, which was automatically closed by github-actions[bot] for inactivity on 2026-10-10. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. Existing PR #5380 remains open and ready for review for the bounded archive/JAR checksum patch. The subsequent CLI-version, full dependency-lock and immutable base-image decisions remain unanswered. This replacement tracks both the existing patch and those unapproved follow-on questions without expanding its scope. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5378. Add reviewed, committed checksums for the existing server Dockerfile’s Node, Maven and MySQL Connector/J downloads, then agree the supported CLI versions and immutable base-image update policy separately. ### Motivation At rocketmq-studio 6a68042f, these versioned archives/JAR are downloaded during image builds without comparing against committed expected bytes. The Dockerfile also installs floating Claude/Qoder versions. Official npm metadata retrieved on 2026-10-02 shows current Claude releases require Node >=22, while this image fixes Node 20.19.2. A blind latest-version pin would not establish a supported combination. ### Describe the Solution You'd Like Immediate bounded patch: - Keep Node 20.19.2, Maven 3.9.9 and MySQL Connector/J 9.7.0, current URLs and licensing separation - Check downloaded bytes against committed official-source SHA-256/SHA-512 values before extraction or runtime placement; fail on curl/checksum errors - Record provenance and update instructions - Exercise actual Dockerfile RUN shell commands offline with synthetic downloads, real checksum tools and mocked extraction/CLI commands Maintainer decision for a subsequent exact npm lock: Should the existing Node-20 image support Claude Code 2.1.197 + Qoder 1.1.65, or is there a different known-working pair? These versions declare compatible Node engines; runtime/native compatibility remains untested. No exact prior working pair was found in repository history. After agreement, use a dedicated package.json/package-lock.json and npm ci, include optional native packages, review required install scripts, and smoke-test real executable availability/provider behavior. A direct version pin alone would not lock the full graph. Separately: which immutable Dragonwell reference is reachable through supported registry mirrors? The current rolling-tag comment records a real compatibility constraint, so the checksum patch need not change that policy. ### Describe Alternatives You've Considered Fetching a checksum from the same mirror on every build does not establish a reviewed fixed input. Upgrading Node or restoring an unreachable Dragonwell patch tag would broaden this change. Checksums protect fixed bytes, but do not establish publisher-signature authenticity or make the entire image reproducible. ### Additional Context No overlapping checksum proposal found after searching open/closed issues and PRs for Docker, checksum, qodercli, Dragonwell and supply-chain. Related: #2650 (earlier base pin), #5007 (licensing separation), #2723 (frontend reproducibility), #4625 (separate rmqctl installer). Official candidates: https://registry.npmjs.org/@anthropic-ai/claude-code/2.1.197 and https://registry.npmjs.org/@qoder-ai/qodercli/1.1.65. Claude 2.1.198 begins the newer Node >=22 requirement in the inspected stable release history. The checksum patch has 18 passing offline shell scenarios and independently matched official/mirror bytes; no full Docker build is claimed. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
