Summary
The unit lane is also failing in pkg/container because FuzzDockerExecSecurity seed cases are currently treated as hard test failures during normal go test execution.
Evidence
npm run ci:unit --silent later failed in pkg/container after the #291-#294 fixes were already green in their targeted packages.
- Failing seeds included examples flagged as
Null byte in exec parameters, Environment manipulation in arg 0: "PATH=/evil", and Path traversal in command: "../../bin/sh".
- The package run also emitted a coverage export error after those failures.
Why this matters
- It is a separate red build source unrelated to the issue-set fixes.
- Security-focused fuzz tests should produce reproducible, intentional signals, not unexpectedly break the general unit lane.
Proposed work
- Decide whether these cases belong in the normal short/unit lane or only in a dedicated fuzz/security lane.
- Rework the fuzz oracle so malicious input is distinguished from an actual product regression.
- Add deterministic regression tests for the intended blocked cases and keep fuzzing focused on discovery.
- Ensure coverage generation remains stable when these tests run.
Acceptance criteria
npm run ci:unit --silent does not fail because of pkg/container fuzz seeds.
- The security intent of the tests is preserved and documented.
- Lane ownership between unit and fuzz runs is explicit.
Summary
The unit lane is also failing in
pkg/containerbecauseFuzzDockerExecSecurityseed cases are currently treated as hard test failures during normalgo testexecution.Evidence
npm run ci:unit --silentlater failed inpkg/containerafter the #291-#294 fixes were already green in their targeted packages.Null byte in exec parameters,Environment manipulation in arg 0: "PATH=/evil", andPath traversal in command: "../../bin/sh".Why this matters
Proposed work
Acceptance criteria
npm run ci:unit --silentdoes not fail because ofpkg/containerfuzz seeds.