fix(deps): override postcss and sharp — the last two advisories in the image - #350
Merged
Conversation
…e image ui#344 identified these and deliberately left them: both are unreachable today, and neither is fixable by a version bump, because Next 16.2.12 pins postcss to 8.4.31 exactly and declares sharp ^0.34.5. Clearing them needs `overrides`, which swaps Next's internal CSS pipeline, so it wanted its own change with its own build check rather than riding along with a lockfile-only PR. They are now the only thing left. After ui#349 removed npm from the runtime image, Trivy on the built artifact reports exactly these: postcss x2 and sharp. With these overrides it reports zero. postcss 8.4.31 -> 8.5.25 across the whole tree including the copy nested under next. The risk was that this rebuilds every stylesheet through a different postcss: it does not change a byte. The largest emitted stylesheet has the same content hash in both builds (0u2h44mgsyx9m.css, md5 c7a459c459e745be8b4ff6dddba21382), which is the strongest available evidence that the pipeline swap is inert. sharp 0.34.5 -> 0.35.3 is a major (libvips 8.17 -> 8.18). Nothing calls it: no images: block in next.config.ts, next/image imported in zero files, and /public holds five SVGs, which bypass sharp entirely. It is upgraded pre-emptively because it is the one item that would become reachable the moment someone adds an images.remotePatterns entry — at which point the advisory stops being theoretical and nobody rereads the triage. Verified: npm ci, tsc, 866 tests, a full next build, and a Trivy scan of the production image reporting 0 HIGH/CRITICAL.
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.
Why now
ui#344 found these and deliberately left them:
They are now the only thing left. After ui#349 removed npm from the runtime
image, a Trivy scan of the built production image reports exactly these three
alerts — postcss ×2, sharp ×1 — and they are what keeps the Trivy check red on
the v0.4.0 release PR.
With these overrides the image reports 0 HIGH/CRITICAL.
Neither is fixable by a version bump: Next 16.2.12 pins
postcssto 8.4.31exactly and declares
sharp: ^0.34.5.overridesis the only mechanism.postcss 8.4.31 → 8.5.25
Applied tree-wide, including the copy nested under
next:The risk was real: this rebuilds every stylesheet through a different postcss.
It does not change a byte. The largest emitted stylesheet has the same
content hash in the override build and the develop build —
— with 41
--background/--foregroundtoken references and 476 dark-modeselectors intact. Next generates the CSS filename from a content hash, so
identical names across two independent builds is about as direct as this
evidence gets.
sharp 0.34.5 → 0.35.3
A major (libvips 8.17 → 8.18), and nothing calls it: no
images:block innext.config.ts,next/imageimported in zero files,/publicholds fiveSVGs which bypass sharp entirely.
Upgraded pre-emptively anyway, because it is the single item that would become
reachable the moment someone adds one
images.remotePatternsentry — and atthat point nobody rereads a months-old triage note. Being unreachable by
configuration is not the same as being safe.
Verified
npm citsc --noEmitvitest runnpm run build