[quality] pkg/proxy write-gate coverage gaps: NewGitHubProxyEphemeral 0%, forwardPlainDirect 502 branch, handleTransparentTLS 60.8%

[kubestellar-hive]

Finding

pkg/proxy is the lowest-covered Go package (91.9% at v4 5c9ab17) while being the security-critical MITM write gate for all agent GitHub traffic. Function-level gaps:

• NewGitHubProxyEphemeral (github_proxy.go:336) — 0% within ./pkg/.... Only exercised from cmd/hive/boot_proxy_deps_test.go, and CI's coverage run is pkg-scoped, so regressions in the ephemeral constructor (allowlist wiring, router/entitlement init) would be invisible.
• forwardPlainDirect (github_proxy.go:1646) — 62.5%: the upstream-failure branch that must return HTTP 502 to the agent was untested.
• handleTransparentTLS (github_proxy.go:499) — 60.8%: several branches of the iptables-redirect path (UID attribution fallbacks, internal-caller naming, Copilot sniff gating) untested.

Recommendation

1. Add pkg-local tests for the ephemeral constructor and the plain-HTTP 502 branch — done in the linked hold-gated PR.
2. Follow-up: exercise handleTransparentTLS's attribution branches (uidMap present/absent, internal UID naming, non-inspected host tunnel) via net.Pipe + synthetic ClientHello, as clienthello_record_test.go already does for framing.

Priority

• Impact: high (write-gate enforcement surface)
• Effort: low for items 1; medium for handleTransparentTLS

---

Filed by quality agent (hold-gated mode)

🐝 Hive Agent: quality | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=quality backend=copilot model=claude-fable-5

[github-actions]

PR #7794 has merged (#7794) and referenced this issue with a non-closing Refs #7793 rather than a closing keyword.

Can this issue now be closed, or is there remaining work it should keep tracking?

[github-actions]

@kubestellar-hive[bot] this issue was closed by @clubanderson as completed.

If this was closed by a merged PR, the fix only takes effect once it ships in a tagged release and your deployment updates to it — check your running version against the fix before concluding the fix failed.

If you are still seeing the problem, comment /reopen and it will be reopened for you — you do not need write access. Please add what you are still observing (running version, logs, steps) so it is not closed the same way again.