fix: cleanse generated BLS secret candidate - #7606
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe BLS implementation adds the Estimated code review effort: 1 (Trivial) | ~2 minutes Mergeability Score: ⚪ Minimal · up to This localized change cleanses the generated secret candidate after key generation; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
✅ Final review complete — no blockers (commit 9c3f4ff) |
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Codex/Sol only (Phase 2 disabled)
At exact head 9c3f4ff, the change correctly cleanses the temporary 32-byte BLS secret candidate after successful key construction and before publishing the key as valid. The new include is guarded consistently with MakeNewKey(), and no in-scope defects or actionable findings were identified.
Source: reviewer backend model gpt-5.6-sol; final verifier backend model gpt-5.6-sol. openclaw-agent/cliproxy/gpt-5.6-sol is orchestration-only and is not reviewer evidence.
Validated zero-blocker Codex/Sol precheck evidence was promoted to final because Phase 2 (Sonnet/Opus) is temporarily disabled. This is Codex/Sol-only final validation, not Codex + Sonnet/Opus coverage.
Review provenance
- Codex reviewers:
gpt-5.6-sol— general (completed) - Verifier:
gpt-5.6-sol— verifier - Sonnet/Opus: not run (Phase 2 disabled — temporary Codex/Sol-only final)
- Secondary pass: disabled (
temporary_phase2_sonnet_disable)
Issue being fixed or feature implemented
CBLSSecretKey::MakeNewKey()retains the accepted 32-byte random candidate inits stack buffer after constructing the secret key. The candidate is private
key material and should not remain recoverable from the stack longer than
necessary.
This is an existing issue in random BLS generation, including the
bls generateRPC. It is intentionally split from #7594 because thewallet-derived operator-key path does not call
MakeNewKey().What was done?
Cleanse the candidate buffer immediately after the key-generation retry loop,
before publishing the resulting key as valid.
How Has This Been Tested?
make -C src -j6 test/test_dashsrc/test/test_dash --run_test=bls_tests(20 cases passed)test/lint/lint-includes.pytest/lint/lint-whitespace.pygit clang-format --diff upstream/develop -- src/bls/bls.cppgit diff --checkTested on macOS 15/Apple Silicon using the repository depends toolchain.
Breaking Changes
None.
Checklist:
This pull request was created by Codex.