refactor(policy)!: remove deprecated NetworkBinary.harness #3054

Activity

1. drew

   added a parent issue on Aug 31, 2026

   • Stabilize public API, SDK, and extension contracts for 0.1.0 #2565
2. github-project-automation

   added this to OpenShell Roadmapon Aug 31, 2026
3. github-project-automation

   moved this to Todo in OpenShell Roadmapon Aug 31, 2026
4. varshaprasad96 commented on Sep 4, 2026

   

   varshaprasad96

   on Sep 4, 2026

   Contributor

   More actions

   📋 triage-agent

   Triage Assessment

   Classification: validated-feature

   Summary

   The deprecated public field and dead generated SDK surface are confirmed on current main, and removing the field during the coordinated pre-0.1.0 breaking-change window is technically coherent. The field is not fully ignored internally, however: runtime code repurposes it as policy-advisor provenance in a security-sensitive SSRF approval flow. Removal must preserve that behavior through an internal representation and regression coverage.

   Investigation

   • proto/sandbox.proto declares NetworkBinary.harness as deprecated field 2, and generated Go protobuf bindings still expose it. Normal policy YAML accepts and discards the legacy key, while provider-profile YAML still serializes, deserializes, and converts it.
   • Policy merge, advisor proposal creation, and OPA projection read or write the bit as advisor_proposed provenance. Rego uses that provenance, together with endpoint provenance, when deciding whether an exact hostname may bypass the default private-address SSRF block.
   • PR fix(sandbox): trust exact declared private endpoints #1560 introduced and tested this provenance behavior after identifying a possible SSRF bypass if advisor provenance is lost. A focused run of the existing supervisor-network regressions passed: both advisor-proposed binary and endpoint cases remain excluded from exact-declared-host trust.
   • Persisted policy revisions and draft chunks contain protobuf-encoded policy/rule data. Reserving tag 2 and the name harness is the correct schema direction, but compatibility tests must confirm how legacy tag-2 payloads decode in each supported runtime and whether unknown bytes are dropped or preserved.
   • The latest release is v0.0.116 and current main still contains the field, so there is no released fix. No duplicate or fixing PR was found. Stabilize public API, SDK, and extension contracts for 0.1.0 #2565 is the parent API-stabilization tracker, not a duplicate.
   • No issue version was supplied, but current-source validation makes that non-blocking. The definition of done should explicitly require unchanged policy-advisor/SSRF behavior; the remaining provenance representation, legacy profile-YAML handling, and migration-note placement are implementation-time choices rather than triage blockers.

   Impact Signals

   • Affected users/scope: Direct protobuf/raw SDK consumers, provider-profile authors, persisted policy/draft compatibility, and policy-advisor/merge/runtime enforcement paths.
   • Regression: No; this is longstanding deprecated surface and compatibility debt.
   • Workaround: Consumers can ignore harness, but that does not remove the misleading generated API or legacy profile representation.
   • Evidence quality: High; confirmed from current source, generated bindings, persistence paths, historical PR rationale, duplicate/release checks, and focused passing regression tests.

   Human Decision Required

   Decide whether OpenShell should address this issue. If yes, apply
   state:accepted, associate it with a roadmap item, or do both, and decide
   whether the work remains human-owned. Either action records acceptance;
   roadmap placement additionally records sequencing.
   To queue investigation or planning for an unattended agent, also apply
   agent:plan-requested. You can instead directly ask an agent to use
   create-spike or build-from-issue on this issue; the agent will warn about
   missing expected workflow labels and continue without changing them. If no,
   close it as not planned and record the rationale.
5. varshaprasad96 commented on Sep 4, 2026

   

   varshaprasad96

   on Sep 4, 2026

   Contributor

   More actions

   This is a straight-forward change. Will create a PR for this
6. github-project-automation

   moved this from Todo to In progress in OpenShell Roadmapon Sep 8, 2026
7. varshaprasad96 commented on Sep 8, 2026

   

   varshaprasad96

   on Sep 8, 2026

   Contributor

   More actions

   🏗️ build-from-issue-agent

   Implemented in #3222.

   • Removed and reserved NetworkBinary.harness, then updated bindings and call sites.
   • Preserved advisor provenance, including collision-safe rule separation and legacy stored-policy migration.
   • Added migration documentation and regression coverage.
   • Validation: pre-commit and Rust, Go, TypeScript, and Python suites pass.
   • Docker E2E could not start because the local Docker daemon was unavailable.
8. johntmyers

   added 2 commits that reference this issue on Sep 10, 2026

   refactor(policy)!: remove NetworkBinary harness field

   ...

   This issue will close once commit 0d8f7a3 is merged into the 'main' branch.

   0d8f7a3

   refactor(policy)!: remove NetworkBinary harness field

   ...

   This issue will close once commit c3c4484 is merged into the 'main' branch.

   c3c4484
9. johntmyers

   closed this as completedin #3222on Sep 11, 2026
10. github-project-automation

    moved this from In progress to Done in OpenShell Roadmapon Sep 11, 2026
11. winnyschuster

    added a commit that references this issue on Sep 11, 2026

    refactor(policy)!: remove NetworkBinary harness field (NVIDIA#3222)

    ...

    This issue will close once commit 0803c4a is merged into the 'main' branch.

    0803c4a