Introduce separate signing keys table - #8304
Open
Max (maxtropets) wants to merge 1 commit into
Open
Conversation
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The reviewed changes have no unresolved approval-blocking issues.
Pull request overview
Separates service TLS and ledger-signing identities into dedicated tables while preserving legacy ServiceInfo compatibility.
Changes:
- Adds and populates TLS and signing identity tables.
- Preserves signing identities during recovery.
- Updates certificate consumers and signature verification.
- Adds coverage for split identities and recovery continuity.
File summaries
| File | Description |
|---|---|
src/service/tables/tls_identities.h |
Defines TLS identity storage and legacy fallback. |
src/service/tables/signing_identities.h |
Defines signing identity storage and legacy fallback. |
src/service/network_tables.h |
Registers the new identity tables. |
src/service/internal_tables_access.h |
Populates identities and enforces continuity. |
src/node/test/history.cpp |
Tests verification with separated identities. |
src/node/rpc/test/internal_tables_access_test.cpp |
Tests signing identity continuity during recovery. |
src/node/rpc/node_frontend.h |
Returns the TLS identity as the service certificate. |
src/node/recovery_decision_protocol.cpp |
Uses the TLS identity during recovery transitions. |
src/node/node_state.h |
Validates service transitions against the TLS identity. |
src/node/history.h |
Verifies signatures using the signing identity. |
src/node/gov/handlers/service_state.h |
Exposes the TLS identity through governance APIs. |
Review details
- Files reviewed: 11/11 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Max (maxtropets)
force-pushed
the
f/multisign-part-2
branch
from
September 8, 2026 20:37
ae29767 to
64f0775
Compare
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The audit documentation must accurately describe the signing identity value encoding.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 8/8 changed files
- Comments generated: 1
- Review effort level: Balanced
Max (maxtropets)
marked this pull request as ready for review
September 8, 2026 21:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Continuing towards #7848.
Introducing
SigningIdentityas a branch-off fromServiceIdentity.signing_identities = map { IdentityType=CLASSICAL|PQ -> Identity }; onlyCLASSICALis populated.service_info.certas aCLASSICAL-only legacy fallback. Invalid signing material or failed verification does not trigger that fallback.Current service identity still serves as "service identity" in
service_info.cert.ServiceIdentityis the acknowledged service TLS certificate, keeping renewal via proposal and the existing certificate-based recovery flow.transition_service_to_openkeeps its previous/next certificate checks. The existing classical endorsement chain continues endorsing previous service signing keys without changing its schema or behaviour.Not in this PR