fix: Windows binaries panicked on every scan; test on Windows in CI - #46
Merged
Conversation
A checkout with git's autocrlf default on Windows converted the committed rule documents to CRLF, so the byte sequence locating the rules list in the embedded pack never matched and every scan panicked. Every published Windows binary was affected. Force LF for all text files via .gitattributes, and normalize the embedded documents before the pack is assembled so a converted checkout still builds a working binary.
aksOps
changed the title
The escape-filename fixtures cannot exist on Windows - control characters are illegal in file names there, which also means the attack they model cannot arrive that way - so those tests are unix-only. The help test now asserts the usage forms without the binary name, which clap renders as siloscan.exe on Windows.
exclusion_under compared a canonicalized scan root against a raw fallback spelling whenever the cache directory did not exist yet. On Windows the two spellings (verbatim long form vs 8.3 short names) never share a prefix, so the exclusion silently vanished and a scan with --cache-dir inside the root walked its own cache. Paths that do not exist now resolve through their nearest existing ancestor. Silo and rule path globs are matched against forward-slash relative paths on every platform, so their syntax is now pinned: backslash escapes everywhere, instead of globset's Windows default of treating it as a separator. Test fixtures: the foreign-salt test copies the salt by read and write because fs::copy cannot copy attributes onto an NTFS alternate data stream, and the global-excludes fixture writes its gitconfig path with forward slashes because git config treats backslash as an escape.
The ignore crate expands every tilde in a configured excludesFile path to the home directory, not only a leading one. Windows temp paths carry 8.3 short names like RUNNER~1, which that expansion corrupts into a path that opens nothing. The fixture now uses the canonical spelling, which carries no tilde.
Merged
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
1 participant
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.
The new Windows CI job failed on its first run, and the failure is a shipped production defect, not a CI problem.
The defect
The repository had no .gitattributes, and git's
autocrlfdefault on Windows converts text files to CRLF at checkout. The rule packs are embedded withinclude_str!and their rules list is located by the exact byte sequence\nrules:\n- which a CRLF checkout does not contain. Result:default_rules()panics, and every published Windows binary (v1.0.x through v1.5.0) panics on any scan that uses the default rules - which is every scan without--no-default-rules. Dead on arrival.Reproduced on Linux by converting the two rule documents to CRLF: same panic, same line, both in the test suite and in a real scan.
The fix, both layers
.gitattributeswith* text=auto eol=lf- every checkout on every platform now produces the bytes the code was tested againstdefault_pack.rsnormalizes CRLF out of the embedded documents before assembling the pack - a converted checkout (or any future include path) still builds a working binaryVerified under CRLF simulation: the previously-panicking test passes and a real scan reports findings.
The CI job
windows-latest:cargo build, fullcargo test(first time any test executes on Windows, including thecfg(windows)NTFS alternate-data-stream cache paths), and a smoke step running the compiled binary against a runtime-generated credential, asserting the finding.This is the job that caught the defect. It should have existed at v1.0.
Follow-up after merge
Tag v1.5.1 so a working Windows binary actually ships.