zmuxuny opened a new issue, #6026: URL: https://github.com/apache/rocketmq-dashboard/issues/6026
### 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 #5382, 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. The signed-release trust-root, rollout and legacy-version policy remain unanswered. This is still a design request, with no signature-verification implementation or release-setting change proposed for immediate submission. 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 #5382. Agree the release-producer and trust-root contract before adding signature verification to rmqctl/install.sh. Retain the existing checksum verification while defining a coordinated signed-release rollout. ### Motivation The current package-release.sh emits an archive plus SHA-256 sidecar, and install.sh retrieves both from the selected GitHub release. This verifies matching bytes. A publisher-authentication feature also needs release signatures, an independently established signer identity, and rotation/revocation rules. A verifier-only change would reject current release artifacts. #4625 already fixed the archive/checksum naming contract; this proposal is a separate enhancement. ### Describe the Solution You'd Like First maintainer question: are the prebuilt rmqctl assets intended to use the RocketMQ ASF release-signing process and its release-manager keys, and which first version can guarantee signatures for every supported platform? Proposed staged contract: 1. Release production emits a detached signature for every exact archive alongside its existing checksum, documents the signer/trust source and never stores signing private keys in source or ordinary build configuration. 2. Publish the authorized full signer fingerprints/key-rotation procedure through the project-controlled release documentation/KEYS process. The installer must not treat any arbitrary key downloaded beside an artifact as sufficient trust. 3. Only after signed artifacts are available, verify checksum and signature before extracting/installing. Use an isolated verification keyring or operator-supplied trusted keyring, do not modify a user’s personal trust database, and fail clearly for tampering, untrusted signer, missing signature or unavailable verifier. 4. Test the actual packaging/install naming contract offline with tampered bytes, wrong signer, missing sidecars, changed version/platform, key rollover and interrupted downloads. Document how users verify the installer itself. Please choose the legacy-version policy too: require signatures for the first signed version onward and reject older versions with migration instructions, or retain an explicitly documented legacy install path? No silent downgrade when verification fails. ### Describe Alternatives You've Considered Checksums remain useful for integrity but do not alone define publisher identity. Fetching a public key from the same arbitrary asset location without authenticating its fingerprint would not solve that. A separate CI provenance/attestation mechanism could complement the release process if maintainers want it; it should not silently replace the project’s agreed signing requirements. ### Additional Context Inspected rocketmq-studio at 6a68042f. Searched issues and PRs for rmqctl signing, signatures, provenance and checksums; no equivalent signed-release contract found. Related merged PR #4625 and issue #4626 concern install compatibility. Official references: https://infra.apache.org/release-signing and https://www.apache.org/info/verification This is a release-engineering design request; no publisher compromise or modified artifact is alleged, and no real key or release setting is changed. ### Are You Willing to Submit a Pull Request? - [ ] 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]
