test(input): inject secure-open failures on the primitive the platform uses - #503
Open
kevin9327 wants to merge 1 commit into
Open
test(input): inject secure-open failures on the primitive the platform uses#503kevin9327 wants to merge 1 commit into
kevin9327 wants to merge 1 commit into
Conversation
…m uses Two cases prove the failed-secure-open contract by patching skillspector.input_handler.os.open. _HAS_SECURE_DIR_FD is False on Windows, so _open_regular_file_no_follow dispatches to _open_regular_file_from_windows_handle and os.open is never called. The failure is never injected there: the file is read normally, and both cases fail while asserting the contract they exist to protect. Deny both primitives so the failure reaches the dispatcher on either platform. The Windows stub raises _FileOpenError, which is what the real helper raises when CreateFileW fails. Signed-off-by: kevin9327 <[email protected]>
rng1995
approved these changes
Sep 12, 2026
rng1995
left a comment
Collaborator
There was a problem hiding this comment.
[SkillSpector Review]
Reviewed head fdc5e8fc9212d1cc62be4e0d64f6a6b38fae9a12 — APPROVE.
The tests now inject failure into both secure-open implementations, with the unit test preserving the Windows helper's _FileOpenError contract. This makes the same cleanup and failed-cache behavior observable on POSIX and Windows without changing production code. I found no required changes.
Required checks pass, but GitHub currently reports mergeStateStatus=BEHIND; update against current main and re-run required checks before merging.
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
Two cases assert what happens when the secure, no-follow open fails. Both inject that
failure by patching
os.open:tests/unit/test_input_handler.py::test_resolve_file_open_failure_does_not_create_temp_dir— "Failed secure opens leave no handler-owned temporary directory behind."
tests/nodes/test_build_context.py::test_build_context_reports_read_error_without_fake_empty_content— "Unreadable files remain inventoried but are absent from the content cache."
os.openis only reached on the POSIX branch:os.supports_dir_fdis empty on Windows, so_HAS_SECURE_DIR_FDisFalseand the dispatchergoes to
_open_regular_file_from_windows_handle, which opens throughCreateFileWand nevercalls
os.open. The patch therefore injects nothing: the open succeeds, the file is read, andthe assertions about the failure path never get a failure to observe.
The visible effect is that both cases fail. The substantive effect is that the failed-open
contract — no temporary directory left behind, no fabricated empty content in the cache — has
no coverage at all on the platform that uses the handle-based implementation.
Fix
Deny both primitives, so the failure reaches the dispatcher whichever branch it takes. The
Windows stub raises
_FileOpenError, which is exactly what_open_regular_file_from_windows_handleraises when
CreateFileWreturnsINVALID_HANDLE_VALUE:On POSIX the added patch targets a helper that branch never calls, so behaviour there is
unchanged and the cases keep exercising the real
os.openpath.Reproduction
Windows 11, Python 3.12.10, against unmodified
main(704bc95):DID NOT RAISEand the populatedfile_cacheare the same symptom: the open was never denied.With this change, same command:
They pass rather than skip, so the contract is now actually asserted on this platform.
What must still hold
Both files in full, before and after:
tests/unit/test_input_handler.pytests/nodes/test_build_context.pyIn both files the change converts exactly one case from failing to passing and moves nothing
else. The eleven remaining
test_build_context.pyfailures are unrelated to secure-opendispatch and are not touched here.
ruff check src/ tests/—All checks passed!ruff format --check src/ tests/—223 files already formatted