feat(pcc-node): #235 signing-proof registration — prove the node's Ed25519 log-signing key - #250
Open
LamaSu wants to merge 1 commit into
Open
feat(pcc-node): #235 signing-proof registration — prove the node's Ed25519 log-signing key#250LamaSu wants to merge 1 commit into
LamaSu wants to merge 1 commit into
Conversation
…og signing key at registration (#235) pcc-node now proves possession of the node's Ed25519 signing key when it registers, POSTing {id, signingKeyAlgorithm:ed25519, signingPublicKey, signingProof} to /api/kernels (the ed25519 lane). signingProof is a detached Ed25519 signature over the kernelId-bound challenge pcc-kernel-signing-key:{id} (byte-identical to the gateway's kernelSigningProofMessage). KEY CHOICE — ed25519, not secp256k1 (follows the evidence per the task's own instruction). Verified against lamasu/master: the pcc-node machine-log producer (log_capture) signs the machine.execution_log hash chain with the node's Ed25519 key; the gateway settlement/oracle path resolves the REGISTERED signer to verify those log signatures. pcc-node never uses the secp256k1 KernelKeychain (git grep KERNEL_MNEMONIC over lamasu/master *.py = empty). Hamilton is a pcc-node kernel (README: pip install pcc-node), so its logs are ed25519 — registering a secp256k1 key would bind a signer that never signs the logs (set-once mismatch). Fail CLOSED: register_signing_key raises LogSigningRefused on the HMAC dev fallback (pynacl missing or public != ed25519(secret)); cli 'start' catches it and skips WITH a message so dev flows keep running, never POSTing an HMAC value as ed25519. Ports upstream lamasu/master's shipped, tested implementation. Files: pcc_node/log_capture.py (new: sign_ed25519_utf8/assert_ed25519_available/ LogSigningRefused), pcc_node/register.py (register_signing_key + kernel_signing_proof_message), pcc_node/cli.py (wire into start), tests/test_register.py (+5 TestRegisterSigningKey), tests/test_cli.py (mock in start_flow).
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
1 participant
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.
Adopts upstream pcc_node #235 (register_signing_key + kernel_signing_proof_message, challenge byte-identical to the gateway's kernelSigningProofMessage) onto the hamilton line. KEY CHOICE (verified, corrects the survey): hamilton runs the Python pcc-node whose machine-log signer is the node's Ed25519 key (log_capture.py: Ed25519 ONLY, HMAC dev fallback refused — money path, fail closed); KERNEL_MNEMONIC/secp256k1 KernelKeychain is the TS in-process kernel's signer and never signs these logs, so registering it would be a set-once settlement mismatch. Fail-soft wiring in cli start; 5 new tests; 23 targeted + full pcc-node suite 313 passed. NOTE: prod needs a genuine Ed25519 node key (pynacl / crypto extra) or registration proceeds proofless with a loud skip message. Agent: implementer-hamilton235, orchestrated by fable-adapters-orch.