Repository navigation
fix(harness): accept only registered framework names from clients - #634
mlieberman85 wants to merge 1 commit into
Conversation
Marc-cn
left a comment
There was a problem hiding this comment.
Clean security fix: names only from clients, paths refused before anything loads, operator paths still accepted from the CLI and refused inside the checkout (symlinks resolved), and the marker-file tests prove no step runs. On rebase the spec version needs a bump past what main has now (alpha.18+), and the changelog row will conflict like everyone else's. Good to merge after that.
The harness-loop MCP tools, HarnessState, and the canonical audit pipeline now select a framework only by a registered name. A value that reads as a path, or a name no installed package registers, is refused with an error before any framework file is read or any step runs. resolve_framework_path resolves registered names only. A framework file given by path is still accepted from the operator at launch (darnit audit/plan --framework PATH, darnit serve PATH, darnit validate), and darnit audit and darnit plan refuse one that resolves inside the repository they audit, as operator configuration there is refused. Specified in framework-design 14.5 (1.0.0-alpha.17). Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Michael Lieberman <mlieberman85@gmail.com>
fb72b7d to
ccce2e4
Compare
Marc-cn
left a comment
There was a problem hiding this comment.
Re-approved on ccce2e4 (my earlier review's commit is gone, so I re-read it whole). Path-likeness is refused at every client-facing entry (harness state, agent state, tool argument, audit pipeline), registration is required in HarnessState, commonpath handles the repo/repo-x prefix case and there's a test for it, symlink-into-repo is covered, and the server still takes its framework name from the TOML's metadata.name so darnit serve custom.toml keeps working. test_framework_selection, server and harness suites pass locally.
Summary
The harness-loop MCP tools (
run_next_action,submit_action_result) tookframework_namefrom client state, andresolve_framework_pathtreated any value containing/or ending in.tomlas a path. A client could therefore point darnit at a framework file committed to the audited repository, and darnit would run that file'sexecsteps. Clients now select a framework by registered name only.HarnessState.framework_name, the harness-loop tools andrun_sieve_auditrefuse path-like values and unregistered names before anything is loaded or run. Path-like means containing/or\, ending in.toml, starting with.or~, or absolute.darnit auditanddarnit plan --framework PATHrefuse a file whose real path is inside the audited repository, as operator configuration there already is.darnit serve PATH,darnit validate PATH, and--framework PATHoutside the checkout.darnit run|harness|serve --frameworktake names only, as their help text already said.Testing
tests/darnit/server/test_framework_selection.py(28 tests).validate_syncare clean..darnit/fw.tomlwith anexecstep that writes a marker file, and harness state names that file. darnit refuses it and writes no marker.Merge notes: this PR, #635 and #636 each set the spec version to 1.0.0-alpha.17 and add a changelog row; whichever lands later bumps the version. #637 adds framework-design 14.6 right after this PR's 14.5.
AI assistance
Claude Code (claude-opus-5-5) implemented and tested this and drafted this description. Commits carry
Assisted-by: Claude:claude-opus-5-5.