chore(deps-dev): Bump @cloudflare/workers-types from 4.20260702.1 to 5.20260708.1 - #138
Conversation
Bumps [@cloudflare/workers-types](https://github.com/cloudflare/workerd) from 4.20260702.1 to 5.20260708.1. - [Release notes](https://github.com/cloudflare/workerd/releases) - [Changelog](https://github.com/cloudflare/workerd/blob/main/RELEASE.md) - [Commits](https://github.com/cloudflare/workerd/commits) --- updated-dependencies: - dependency-name: "@cloudflare/workers-types" dependency-version: 5.20260708.1 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
released-web | 667d283 | Aug 07 2026, 10:43 PM |
|
liveapp adoption pass @ 40919d5: blocked: osv fails on 2 pre-existing High CVEs in main's pinned deps (undici 7.28.0, js-yaml 4.3.0) — NOT introduced by this @cloudflare/workers-types 4-to-5 bump. This bump's own changes are clean (typecheck/test/build/wrangler dry-run all pass). Resolves once #137 — which carries the undici 7.29.0 / js-yaml 4.3.1 pin bump — reaches main and this PR rebases. Land #137 first. (Workers Builds: released-web fails identically on all open PRs — repo-level config issue, not this bump, not a required check.) |
|
liveapp follow-up @ 667d283: unblocked — fix-forwarded the same 2 High CVEs onto this branch (override floors Local gate green: osv (the gate that was red) + typecheck + build + test; the repo pre-push osv hook also passed on push. Not gated on #137 anymore. Merge order: #137 first is still cleanest (canonical security fix + its 7 bumps); #138/#139 now carry the same CVE fix so they're not blocked on it — but all three rewrite |
Preview deployed
Federated GitLab lookups (freedesktop / GNOME) degrade to the "use the CLI" card — the Anubis relay is off in preview. GitHub lookups, permalinks, and OG render work once |
|
liveapp adoption pass @ 667d283: adopted — @cloudflare/workers-types 4.20260702.1→5.20260708.1 (types-only dev-dep). Fix-forwarded the 2 pre-existing High CVEs in main's pinned deps (undici→7.29.0, js-yaml→4.3.1); those pre-date this bump and were what failed the osv gate. GA gate green at this head (tests ×4 platforms, osv, deploy-config dry-run, preview deploy, a11y, secret/shell lints; typecheck+build green locally). Only remaining red = Workers Builds: released-web — a pre-existing, non-required Cloudflare dashboard config issue that fails 0s on every PR; not from this bump. Mergeable. |
…h CVEs The osv gate fails on this branch for CVEs inherited from main, not from this PR's diff: - undici 7.28.0 -> 7.29.0 (GHSA-4cwx-7wf7-3272, High 7.4, +4 more) - js-yaml 4.3.0 -> 4.3.1 (GHSA-5p4m-2wfm-xmqj, High 7.5) - nanoid 3.3.16 -> 3.3.18 (GHSA-2v37-7h3g-55p8, High 8.2) undici and js-yaml match the floors PRs #137/#138/#139 already carry. nanoid is a newer advisory that none of them cover, so this is currently the only open PR that takes main to zero High. Lockfile-only resolution changes; all transitive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Same 2 pre-existing High CVEs as #137 (undici 7.28.0 GHSA-4cwx-7wf7-3272, js-yaml 4.3.0 GHSA-5p4m-2wfm-xmqj) in main's pinned deps — not introduced by the @cloudflare/workers-types 4→5 bump. Bumping the override floors clears them. Local gate green: osv + typecheck + build + test.
667d283 to
e89fe7e
Compare
|
liveapp: re-pushed this branch to retire a dead check, no content change. The only red here was Fix: amended the head commit ( While here, re-verified the CVE position on this branch with |
… High) This branch already pinned undici>=7.29.0 and js-yaml>=4.3.1 to clear two High advisories. A third has landed since: GHSA-2v37-7h3g-55p8 (CVSS 8.2, High) affects nanoid < 3.3.18, and this lockfile resolved nanoid to 3.3.17. The osv gate on this PR last ran 2026-08-12, before that advisory published, so its green is stale — merging as-is would land a High on main and re-red the dependency gate for every open PR (issue #145). Verified against api.osv.dev: nanoid@3.3.17 -> 1 advisory, GHSA-2v37-7h3g-55p8 (HIGH) nanoid@3.3.18 -> 0 advisories undici@7.29.0 -> 0 advisories js-yaml@4.3.1 -> 0 advisories postcss@8.5.25 was already in the tree; the tsup peer line in the lockfile is resolution metadata, not a new dependency. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pushed a fix: this PR's green osv check was stale
What changed underneath it: GHSA-2v37-7h3g-55p8 (CVSS 8.2, High) was The fix ( "js-yaml@4": "^4.3.1",
+ "nanoid@3": "^3.3.18",Verified, not assumed — queried
And the actual gate script, run locally on this branch via the pre-push hook: Gate green: 355 tests (cli 45, web 277 + 6 skipped, web-og 27 + 6). One incidental lockfile line: The remaining Mediums on |
… cache-control (#141) ## The bug Every OG image in production ships a **merged** `cache-control` header. Live right now: ``` $ GET https://og.released.blabberate.com/placeholder.png cache-control: public, immutable, no-transform, max-age=31536000, public, max-age=60 ``` `workers-og` builds its response headers as ```js headers: { 'Content-Type': …, 'Cache-Control': 'public, immutable, no-transform, max-age=31536000', ...opts.headers } ``` Object spread is **case-sensitive**, so `renderImage`'s lowercase `'cache-control'` never replaced the library's capitalized `'Cache-Control'` default. Both keys reached `new Response`, where `Headers` merged them into one comma-joined value — and caches honor the **first** `max-age`. ## Why it matters The damage is on the **short**-cached cards. A placeholder render — cold lookup, upstream rate-limit, service-binding miss, or the `notFound` path hit during the `web`→`web-og` deploy window — is deliberately `max-age=60` so the unfurl refreshes once the real answer exists. Instead it went out `immutable` for a year, so one transient failure froze a wrong social card in every downstream cache that honors it. This is a concrete mechanism for the "sustained placeholder on a stably-released MR" behaviour previously observed on the federated PR OG route: once a placeholder was cached, nothing could dislodge it. Front door stayed green throughout — status 200, valid PNG, correct content-type. Only the header was wrong. ## Fix Set `cache-control` on the Response after construction. `Headers.set` is case-insensitive, so it replaces the library default whatever casing the library uses (rather than relying on matching its casing in the spread, which would re-break on a library change). ## Why the tests didn't catch it `test/routing.test.ts` mocked `ImageResponse` with a stub that passed the caller's headers straight through, so it never reproduced the library default. All 11 `cache-control` assertions were **unfalsifiable** — they read back exactly what the caller passed. They were also substring matches (`toMatch(/max-age=60/)`), which pass on the merged value even with a faithful mock. Both were fixed: - the mock now mirrors `workers-og`'s real header construction (capitalized default + case-sensitive spread of the caller's headers); - the 11 assertions are exact-match (`toBe`); - `test/cards.render.test.ts` gets two assertions against the **real** library under workerd — no mock fidelity required. ## Mutation proof Reverting the one-line fix (passing `'cache-control'` back through `ImageResponse`'s `headers` option) while keeping the tests: ``` Failed Tests 10 FAIL test/routing.test.ts > returns a placeholder PNG with SHORT cache when the service binding misses Expected: "public, max-age=60" Received: "public, immutable, no-transform, max-age=31536000, public, max-age=60" FAIL test/cards.render.test.ts > placeholder card: cache-control is EXACTLY the short cache Expected: "public, max-age=60" Received: "public, immutable, no-transform, max-age=31536000, public, max-age=60" …8 more ``` The `Received:` values are byte-identical to what production serves today. Restored → 35/35 pass (27 routing + 8 render). ## Second commit: `fix(deps)` — clearing the red `osv dependency scan` This branch was based on `main`, which carries 3 High CVEs, so the osv gate was red for a reason unrelated to the OG fix. Rather than leave the PR unmergeable, the floors are raised here (root `pnpm.overrides`, lockfile-only resolution changes): | package | main | this PR | advisory | |---|---|---|---| | `undici` | 7.28.0 | 7.29.0 | GHSA-4cwx-7wf7-3272 (High 7.4) + 4 more | | `js-yaml` | 4.3.0 | 4.3.1 | GHSA-5p4m-2wfm-xmqj (High 7.5) | | `nanoid` | 3.3.16 | 3.3.18 | GHSA-2v37-7h3g-55p8 (High 8.2) | The `undici` and `js-yaml` floors are byte-identical to the ones #137/#138/#139 already carry. **`nanoid` is a newer advisory that none of those three cover** — their osv checks last ran 2026-08-07 and passed, which is now stale. So merging #137, #138 or #139 alone leaves main at 1 High; **this is currently the only open PR that takes main to zero High.** Verified locally on this exact tree — the gate goes red → green: ``` before: Total 4 packages affected by 11 known vulnerabilities (0 Critical, 3 High, …) ✗ osv: 0 Critical + 3 High vulnerability(ies) — must be resolved before merge. after: Total 1 package affected by 4 known vulnerabilities (0 Critical, 0 High, 3 Medium, 1 Low) ✓ osv: no High/Critical vulnerabilities. ``` `pnpm lint`, `pnpm -r typecheck`, `pnpm -r test` (357 tests) all green on the merged branch. **Deliberately not fixed here:** the 4 remaining `hono` mediums (4.12.32 → 4.12.34, GHSA-54fx / -79qm / -8j4g / -f23p). `hono` is the production runtime framework and a direct dependency; the osv gate does not block on Medium, and Dependabot's weekly `npm-minor-patch` group already has it in range (`^4.12.32`). Left to that PR so this one stays reviewable. --------- Co-authored-by: liveapp-bot <liveapp-bot@liveapp.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2 participants
Bumps @cloudflare/workers-types from 4.20260702.1 to 5.20260708.1.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)