deps: clear the fourteen advisories Scorecard reports, by version bump only - #43
Open
distronode-com wants to merge 1 commit into
Open
deps: clear the fourteen advisories Scorecard reports, by version bump only#43distronode-com wants to merge 1 commit into
distronode-com wants to merge 1 commit into
Conversation
…p only
OpenSSF Scorecard's OSV check reports fourteen advisories against this tree.
None of them needs a code change; all but one are closed by moving a version.
Go:
GO-2026-6303 · GO-2026-6354 · GO-2026-6355 · GO-2026-5932
golang.org/x/crypto v0.53.0 -> v0.56.0
Nothing behavioural changes here. The affected packages in those four
advisories are x/crypto/ssh and x/crypto/openpgp; this tree imports only
bcrypt and argon2 (internal/keyvault/keyvault.go,
internal/handler/{claim,email_auth,invites}.go, cmd/calnode/reset_admin.go),
neither of which is touched by any of them. The bump is still worth taking so
the module graph stops reporting them.
go.sum moves two lines and no other module moves. The `go` directive goes
from `go 1.26` to `go 1.26.0` because x/crypto v0.56.0 declares `go 1.26.0`
and the go command requires the main module to be at least that; `go 1.26`
alone now fails with "updates to go.mod needed". Same language version,
written out.
GHSA-q7pp-wcgr-pffx
github.com/disintegration/imaging v1.6.2 -> not fixed upstream
Left alone deliberately: there is no fixed release. imaging is also not on a
reachable path for it here. Every call site (avatar.go, branding_settings.go)
goes through decodeUploadedImage in internal/handler/image_upload.go, which
sniffs the content type with http.DetectContentType and rejects anything that
is not JPEG, PNG, GIF or WebP before decoding, and it caps decoded pixels.
imaging itself is only ever asked for imaging.Fit on an already-decoded
image.Image - its decoders are never called.
Frontend:
GHSA-29g2-3rmr-qm68 · GHSA-866w-xmhq-wj7x · GHSA-wqjv-9729-c5q2
@sveltejs/kit ^2.65.1 -> ^2.70.2 (resolves 2.70.3)
All three are in Kit's server runtime, which this project never runs: the
admin app builds with adapter-static and fallback: '200.html' (see
frontend/svelte.config.js) and is served as static files embedded into the Go
binary. The bump is still the right answer rather than an exception note -
the dependency is in the tree, and five minors of Kit fixes come with it.
GHSA-p63j-vcc4-9vmv
@vitest/browser ^4.1.9 -> ^4.1.10 (resolves 4.1.11)
vitest ^4.1.9 -> ^4.1.10 (resolves 4.1.11)
@vitest/browser-playwright ^4.1.9 -> ^4.1.10 (resolves 4.1.11)
Test-only, but rated critical. Vitest's packages peer-depend on each other at
an exact version, so all three move together or pnpm reports an unmet peer.
GHSA-fxqj-rqcc-2cmp · GHSA-r28c-9q8g-f849
postcss 8.5.15 -> 8.5.28 (transitive: vite, shadcn-svelte)
GHSA-28wg-ghj8-5hjv · GHSA-2v37-7h3g-55p8
nanoid 3.3.12 -> 3.3.19 (transitive: postcss)
Both moved inside their parents' existing ranges, lockfile only.
GHSA-pxg6-pf52-xh8x
cookie 0.6.0 -> 0.7.2 (transitive: @sveltejs/kit)
This one needs a pnpm override, which is why there is now an `overrides`
block. @sveltejs/kit 2.70.3 - the newest 2.x - still declares cookie ^0.6.0,
and for a 0.x version that caret means >=0.6.0 <0.7.0, so the fixed 0.7.0
cannot be reached within the range. The override is scoped to that range
(`cookie@^0.6.0`) so it does not touch the separate cookie 1.1.1 that msw
pulls in, which was never affected. Worth flagging for review: forcing a
dependency inside Kit is a maintainer's call. The risk here is small - cookie
0.7.x is the same API with stricter validation of names, paths and domains,
and under adapter-static the Kit code that calls it never executes - but it
is an override and it should be dropped the moment Kit widens its range.
Verified: pnpm install --frozen-lockfile, pnpm build and pnpm test:visual
(Vitest browser mode, 5/5) all pass; pnpm audit reports no known
vulnerabilities. On the Go side go build ./..., go vet ./... and
go test ./internal/keyvault/... ./internal/handler/... all pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes Version-only dependency bumps to clear Scorecard Vulnerabilities noise where a fixed release exists. No application code changes.
golang.org/x/crypto→ v0.56.0 (andgo 1.26→go 1.26.0for the module’s declared language form). Clears the threesshadvisories; this tree only importsbcrypt/argon2.@sveltejs/kit→ 2.70.3 (lock), vitest browser stack → 4.1.11, plus transitivepostcss/nanoidrefreshes. SPA stays onadapter-static.- Scoped pnpm override
cookie@^0.6.0→^0.7.2so Kit’s 0.x caret can reach the patched line without touching msw’scookie@1.1.1.
Verified here: pnpm audit clean, pnpm build OK, go build/vet and keyvault/handler tests pass, govulncheck reports 0 symbol-level hits.
ℹ️ Title/body slightly overstates GO-2026-5932 clearance
The crypto bump is right for GO-2026-6303 / 6354 / 6355. GO-2026-5932 (x/crypto/openpgp) has no fixed release (Fixed in: N/A) and still shows as a module-level finding on v0.56.0 under govulncheck -show verbose. Same class as the imaging entry you correctly left alone: Scorecard may keep listing it after merge even though nothing in this tree calls openpgp. Worth a one-line PR-body tweak so the “fourteen cleared” claim matches what Scorecard will still see (openpgp + imaging).
Technical details
# GO-2026-5932 is not cleared by x/crypto v0.56.0
## Affected sites
- PR description table lists GO-2026-5932 under “From → To” as cleared by the crypto bump
- `golang.org/x/crypto@v0.56.0` still carries GO-2026-5932 at module level (openpgp, all versions)
## Required outcome
- PR title/body should not claim GO-2026-5932 is resolved by this bump; treat it like imaging (unfixed, unreachable)
## Suggested approach (optional)
- Drop GO-2026-5932 from the “cleared” table; note it remains as an unfixed module-level advisory with no call pathGrok ｜ 𝕏
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.
Scorecard's
Vulnerabilitiescheck reports fourteen advisories against this tree. All of them clear with version bumps, and none of them is reachable in this codebase, so this is housekeeping rather than a fix for a live problem.golang.org/x/crypto@sveltejs/kit@vitest/browser(+vitest,@vitest/browser-playwright, which peer-pin each other exactly)postcss(transitive)nanoid(transitive)cookie(transitive, via Kit)Why none of them bites here: the four x/crypto advisories are in
sshandopenpgp, and this tree imports onlybcryptandargon2; the three Kit advisories are in its server runtime, which never runs underadapter-static(the built SPA is embedded and served by Go);@vitest/browseris test-only;postcssandnanoidare build-time.Two things worth a look:
cookieneeded a pnpmoverridesentry ("cookie@^0.6.0": "^0.7.2"), because Kit 2.70.3 still declares^0.6.0and for a 0.x version that caret cannot reach 0.7. It is scoped to that range so msw'scookie@1.1.1is untouched, and it should go the moment Kit widens its own range. If you would rather not carry an override, dropping that hunk leaves one LOW advisory open and nothing else changes.go.mod's directive moves fromgo 1.26togo 1.26.0, because x/crypto v0.56.0 declares the patch form andgo buildrefuses to proceed otherwise. Same language version, spelled out.go mod tidymoved nothing else. The fifteenth entry Scorecard lists, GHSA-q7pp-wcgr-pffx indisintegration/imaging, has no fixed release and is left alone; it is unreachable in any case, since every upload goes throughdecodeUploadedImage's content-type sniff beforeimaging.Fitever sees a decoded image.Verified:
pnpm auditreports no known vulnerabilities;pnpm buildandpnpm test:visual(5/5 in Chromium) pass;go build,go vetand thekeyvaultandhandlertest packages pass.🤖 Generated with Claude Code