Repository navigation
Support command-only P-256 client profiles over Unix sockets - #6293
Draft
schickling-assistant wants to merge 5 commits into
Conversation
This branch has not been deployed
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.
Problem
A read-plus-command pairing currently discards its client-generated key, and paired SDK profiles cannot target a client Unix socket. Requiring message authority merely to retain that key would cross the intended authorization boundary.
Goal
Retain P-256 command-only keys, pair over an explicit absolute client Unix socket, and sign the shared purpose-specific device-result canonical form without granting message authority.
Decisions
Verification
Complexity
Uses the existing SDK key/profile boundary; no additional transport or authorization protocol.
Concerns
Draft dependency stack: #6274 codegen output and its daemon enforcement are required before use. This PR does not authorize enrollment or activation.
Friction & bottlenecks
The canonical generator is awaiting shared build admission. The release-note script exposes validate as a Python function rather than a validate subcommand.
Follow-ups
Consumer integration is in the dependent terminal-client PR; enrollment and live acceptance remain separately gated.
References
Depends on #6274.
Generated dependency integration
Signed append-only merge integrates canonical generated head
36592f7090093ae6fe94a87706e319fca78fca17; current head26520277f3f65e52a0e9135f622c1414a3720b34. No generated file was hand-edited. One exact-head dev5 gate ticket requests the relevant Rust checks with--lane build --profile disk=cargo-warm --max-wait 10800; result pending. The prior pre-generation identity ticket was canceled, not executed.Final generated lifecycle cutover
Current signed head
c87a28e3be8163f3d28295fd8523c8f34429de2dintegrates final canonical generated head7cafdf138efbea937cbefa83323d5d2fc8dda15cappend-only. Supersedes earlier generated-integration and pending-head notes. Both intermediate gate tickets were canceled before admission, so no Rust execution is claimed for them.One final-head dev5 gate ticket now requests
cargo test --locked -p fractal-clientthroughgate-slot --lane build --profile disk=cargo-warm --max-wait 10800 -- nix develop --no-write-lock-file --command .... Receipt pending; no success claimed.Final sequence and item-binding revision
Current head
0bdd35baa9e0d6d98c84b2216325ebaec2297a0bincludes signed merge of regenerated canonical head6fb398ccf5f0b7c08ea0cd1892aa26fdb7a2c006. Previous bg318 (TUI) and bg319 (SDK) ended queue-only without payload or exit-code receipts: both NOT RUN. These are not passing or failing Rust executions.One new exact-head dev5 ticket is pending with the current xvrpad67 gate-slot helper and
--lane build --profile disk=cargo-warm --max-wait10800. No Rust success claimed until its receipt.Current source and exact-head checks
Current signed head
315640a10734395249146f6e8519d1f5137889ccintegrates corrected canonical972b65b7c4cf8e3612ffdd4d756e11d0b7b011f2. Superseded tickets bg419/bg420 were withdrawn while queued with SIGUSR2 and both exited94: NOT RUN, no payload. New exact-head dev5 ticket requests the same crate test command through xvrpad67 gate-slot. Receipt pending.Admission receipt
The first current-head dev5 ticket expired before admission after10800seconds with exit94: Rust tests NOT RUN, no nix/cargo payload executed. The single authorized replacement requests the identical command at the unchanged current head; pending. This is an admission constraint, not a passing or failing test result.
Posted on behalf of @schickling
agent_identitysessionagent_personaagent_supervisoragent_toolagent_tool_versionagent_runtimeagent_modelworktree