lizhimins commented on PR #4219: URL: https://github.com/apache/rocketmq-dashboard/pull/4219#issuecomment-5694501541
Closing, with the reasoning below — the cryptography itself is not the problem. What we verified as correct: the key comes from `STUDIO_CREDENTIAL_ENCRYPTION_KEY` with no hard-coded secret in the repository; the IV is freshly generated per encryption and never reused; the 128-bit tag is validated by JCE so tampering or a key change throws instead of returning garbage; ciphertexts carry an `enc:v1:` prefix; re-authentication is enforced server-side (`CloudCredentialService` -> `AuthService`, session principal only, 403 for empty/wrong/disabled, audited on both outcomes); and `list`/`export` keep masking. No bypass found. Two blocking issues remain. First, the fallback key is the SHA-256 of a public constant in this repository, and the WARNING your javadoc promises for that case is never logged — a deployment can silently run on a guessable key. Second, the backfill seals existing rows with that fallback key and skips rows that already carry the prefix, so configuring a real key afterwards makes the previously migrated credentials permanently unreadable with no re-seal path and no way out from the UI; a single undecryptable row also fails `findAll()` and takes the whole credential list page down. We are not willing to merge encryption whose failure mode is silent, permanent data loss. Please open an issue so we can agree the key policy (no fallback, or no migration until a real key is configured) and then resubmit — the rest of the patch is close. -- 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]
