AST-165915: keep the platform fix without the cloud SDK dependencies - #55
Open
cx-dmitri-rivin wants to merge 1 commit into
Open
cx-dmitri-rivin wants to merge 1 commit into
cx-dmitri-rivin wants to merge 1 commit into
Conversation
…rm fix The platform-mismatch fix shipped alongside an unrelated dependabot bump of syft (v1.21.0 -> v1.42.4) and stereoscope (v0.1.0 -> v0.1.22). The newer syft imports hashicorp/go-getter, whose package-level Getters map unconditionally registers the GCS and S3 backends, so the whole aws-sdk-go-v2 and cloud.google.com/go/* trees became transitive dependencies even though nothing here fetches from S3 or GCS. Reviewers on ast-cli measured the resulting binary growing from 81MB to 113MB for dependencies the CLI never calls. containers-syft-packages-extractor v1.0.27 already re-pinned syft/stereoscope to their pre-bump versions, but this module's go.mod still carried the upgraded requirements from its own tidy, so the cloud SDKs stayed in the graph. Re-tidying against v1.0.27 removes them: go.mod and go.sum are now identical to the pre-fix state apart from the extractor version itself. The fix's behaviour is unchanged - Resolve still calls AnalyzeImages so that each image resolves on the platform it was built for - and it needs no syft or stereoscope API newer than v1.21.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
End-to-end repro on the pinned (v1.21.0) syftConfirming the fix still reproduces and resolves with the old syft/stereoscope, i.e. the dependency bump was never needed for it. Built a single-architecture local image on an arm64 host: Then ran the extractor from this branch's dependency set (syft v1.21.0, stereoscope v0.1.0) both ways: Two things this shows:
Neither part needs an API newer than syft v1.21.0. |
Contributor
|
New Issues (11)
Checkmarx found the following issues in this Pull Request
Fixed Issues (6)
Great job! The following issues were fixed in this Pull Request
Use @Checkmarx to interact with Checkmarx PR Assistant. |
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.
Why
The AST-165915 fix (#53) is correct, but it shipped alongside an unrelated dependabot bump of
syft(v1.21.0 -> v1.42.4) andstereoscope(v0.1.0 -> v0.1.22).The newer
syftimportshashicorp/go-getter, whose package-levelGettersmap unconditionally registers the GCS and S3 backends. That drags the wholeaws-sdk-go-v2andcloud.google.com/go/*trees into the graph even though nothing in this module (or in the CLI) ever fetches from S3 or GCS. Reviewers on the ast-cli bump measured the CLI binary growing 81MB -> 113MB for dependencies the CLI never calls.containers-syft-packages-extractorv1.0.27 already re-pinned syft/stereoscope back to their pre-bump versions, but this module'sgo.modstill carried the upgraded requirements from its own tidy, so the cloud SDKs stayed in the graph and the CLI-side bump did not shrink. This PR re-tidies against v1.0.27.What changed
go.mod/go.sumonly — no source changes.go.modis now byte-identical to the pre-fix state except for the one line that matters:cloud.google.com/*,GoogleCloudPlatform/*,aws-sdk-go-v2/*,smithy-goentriesanchore/syftanchore/stereoscopegodirectiveThe fix itself is unchanged
Resolvestill callsAnalyzeImagesrather thanAnalyzeImagesWithPlatform("linux/amd64"), so each image is resolved on the platform it was actually built for. The extractor-side fix (resolvePlatformreturning nil for "no preference", and themismatched platform/no child with platformerror mapping) is present in v1.0.27 and needs no syft or stereoscope API newer than v1.21.0.Verification
go build ./...,go vet ./...cleango test ./... -count=1— all passmain:main(resolver v1.0.34, pre-fix)+18 KB, i.e. the platform fix costs nothing. For comparison, ast-cli against resolver v1.0.36 pulls in 30 cloud SDK modules and does not even compile (
containerd/v2API conflict).Next step
Once this is tagged, ast-cli is bumped to the new version — a one-line change in its
go.modwith no new dependencies.🤖 Generated with Claude Code