Apply path filters to unpacked archive contents - #1745
Draft
zlav wants to merge 4 commits into
Draft
Conversation
Projects discovered inside an archive unpacked by --unpack-archives live in a temp directory, so filters were evaluated against a path the user cannot name and exclusions never matched. Prepend the archive's FileAncestry path prefix — already threaded through discovery for origin path reporting — to the project's discovered path before applying filters, so `third-party` excludes projects found inside `third-party/lib.zip`. The prefix accumulates across nested archives. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Path.Windows.mkAbsDir rejects absolute paths without a drive letter, and because these are Template Haskell splices it fails at compile time, so test:unit-tests would not build on Windows. Follow the repo's existing idiom (see ForkAliasSpec): one CPP-guarded binding for the filesystem root, with every other path derived from it via mkRelDir and </>. Relative paths parse identically on both platforms, so this keeps a single #ifdef in the file rather than one per test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The existing archive tests hand applyFiltersToProject an already-correct FileAncestry, so nothing covered the code that produces it: a regression in ancestryDirect or convertArchiveToDir would leave all of them green. Pin the invariant that the prefix is exactly the archive's path relative to the scan basedir. The case that matters is a scan rooted below the archive's ancestors (basedir <root>/third-party/user, archive at project/archive.tar): nothing above the basedir may leak in, and no intermediate directory may be stripped. Filters on third-party or user must not match, since those directories are invisible to the scan. These pass against the current implementation; they are regression guards, not a bug report. Export convertArchiveToDir to test it. Also fill in the changelog entry with the user-visible behavior change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Overview
--unpack-archivesignored path exclusions: projects inside an archive were analyzed even when the archive sat under an excluded directory.applyFiltersToProjectevaluated filters against a temp-relative path (maven-project/) that no user filter can name — nothing matched, and the project was analyzed.--unpack-archivesoutright, since it would filter out all archive contents.FileAncestryprefix from ANE-895: full origin path for unpack archives #1231 (already threaded throughDiscovery.Archive.discoverfor origin path reporting) rather than adding new provenance:applyFiltersToProjectnow takes that prefix and prepends it, so filters seethird-party/lib.zip/maven-project/. The prefix accumulates across nested archives.The ticket's pointer at
decompressFilespath filtering in Core is a red herring for this symptom — the leak is CLI-side, at the filter callsite.Testing plan
test/App/Fossa/AnalyzeSpec.hs, passing: exclude/include filters on archive contents, nested archives-in-archives, and four covering how the prefix is derived — it must be exactly the archive's path relative to the scan basedir, leaking no ancestor above the basedir and stripping no intermediate directory.unit-testssuite: 1432 examples, 27 failures, all pre-existing in untouched modules (Lernie / Themis / Conan) with the sameCodec.Compression.Lzma: decoding errorfrom the absentvendor-bins/binaries in this checkout.Risks
Behavior change for anyone relying on
--unpack-archivesto scan archives that sit under an excluded path.References