fix: detect source archives by content, not filename substring (#4582)#5021
Open
arpitjain099 wants to merge 1 commit into
Open
fix: detect source archives by content, not filename substring (#4582)#5021arpitjain099 wants to merge 1 commit into
arpitjain099 wants to merge 1 commit into
Conversation
fileAnalysisPath called IdentifyArchive with a nil reader, so mholt/archives fell back to filename-only matching. That matching uses strings.Contains, so a regular file whose name merely contains an archive extension as a substring (for example sample.tar.gz_hashed.json) was treated as a gzipped tar and scanning failed with "unable to unarchive source file: gzip: invalid header". Open the file and pass the reader to IdentifyArchive so content-based detection runs. Non-archives now fall through to regular file analysis, while genuine archives are still extracted. Fixes anchore#4582 Signed-off-by: arpitjain099 <arpitjain099@gmail.com>
spiffcs
approved these changes
Jun 29, 2026
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
2 participants
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.
Description
fileAnalysisPath calls IdentifyArchive with a nil reader, so mholt/archives can only match on the filename, and it does that with a substring check (strings.Contains lowercased for ".gz", ".tar", etc). That means any ordinary file whose name happens to contain an archive extension gets treated as an archive and the scan fails. The reported case is a JSON file named sample.tar.gz_hashed.json, but as @kzantow pointed out on #4582 even a real binary named syft.tar.gz.bin trips it. This worked fine in 1.36.0 and regressed sometime after.
The fix opens the file and hands the reader to IdentifyArchive so detection runs on content. Non-archives fail the header check, get no extractor, and fall through to normal file analysis; genuine archives still match on their header and extract as before.
One thing worth flagging: with content-based detection, a file named like an archive but not actually valid (including a genuinely corrupt .tar.gz) now falls through to plain file analysis instead of erroring. That matches pre-1.36 behavior and seems like the better default for a tool you point at arbitrary files, but it does mean a truly broken archive gets analyzed as a regular file rather than surfacing the corruption. If you'd rather keep an explicit error for that, or tighten the alias handling in internal/file/archive_aliases.go instead, happy to rework it - just say which way you'd prefer.
Type of change
Checklist
Issue references
Fixes #4582