Skip to content

fix(deps): bump electron to 42.11.12 - #49

Open
lacymorrow wants to merge 1 commit into
lashfrom
security/electron-42.11.12
Open

lacymorrow wants to merge 1 commit into
lashfrom
security/electron-42.11.12

Conversation

@lacymorrow

Copy link
Copy Markdown
Owner

Five high advisories off the 2026-09-15 supply-chain baseline, all five in electron and all five cleared by one bump. Part of LACA-2116, the follow-up to the criticals in LACA-2111.

What moved

packages/desktop devDependency electron, 42.3.3 to 42.11.12.

advisory first patched
GHSA-qmv3-fv6v-rmhq 42.10.0
GHSA-hq2x-r82h-9wj4 42.5.2
GHSA-9qh4-3jw8-366w 42.9.2
GHSA-gr2m-v5gq-v685 42.9.2
GHSA-j84w-jfhq-vhvj 42.9.2

42.10.0 is the highest floor, so that is the minimum that clears all five. I went to 42.11.12 instead, the newest release still on the 42 line, so this does not come back as a sixth alert next month. The old pin was 42.3.3, which means this is a minor move inside major 42 and no Electron API breakage is in play. Upstream is on 44 now, but chasing that is a separate conversation from a security bump.

The bun.lock diff is bigger than the bump, and most of it is not mine

bun.lock shows 23 insertions and 67 deletions. That looked wrong, so I measured it instead of guessing. I installed on a clean checkout of the parent commit, with no electron change, and diffed three ways: the committed lock, the clean reinstall, and this branch.

18 lock entries are pre-existing drift. Any bun install on dev produces them, with or without this PR. The committed lock is simply stale against the committed package.json files. Two parts to it:

  • An orphaned @vitest/coverage-v8 chain gets dropped: @vitest/coverage-v8, @vitest/utils, @vitest/pretty-format, magicast, ast-v8-to-istanbul, js-tokens, @bcoe/v8-coverage, the four istanbul-* entries, html-escaper, make-dir, plus encoding and iconv-lite. grep -r coverage-v8 --include=package.json finds nothing, so no workspace package asks for it anymore. Also two duplicate effect@4.0.0-beta.74 subtrees under @standard-community/*.
  • Fifteen workspace version lines resync from 1.7.13 and 1.18.29 to 1.7.14, matching what the release: v1.7.14 commit already put in the package.json files.

11 lock entries are actually from the electron bump, and they all trace to one upstream change. Electron 42.11.12 replaced its extract-zip@^2.0.1 dependency with @electron-internal/extract-zip@^1.0.1:

  @electron-internal/extract-zip  (absent) -> 1.0.5
  electron                        42.3.3   -> 42.11.12
  extract-zip                     2.0.1    -> (removed)
  yauzl                           2.10.0   -> (removed)
  yauzl/buffer-crc32              0.2.13   -> (removed)
  fd-slicer                       1.1.0    -> (removed)
  pend                            1.2.0    -> (removed)
  @types/yauzl                    2.10.3   -> (removed)
  get-stream                      5.2.0    -> 8.0.1
  cacheable-request/get-stream    (absent) -> 5.2.0
  execa/get-stream                8.0.1    -> (removed)

The get-stream rows are a hoist shuffle, not a version change in disguise. 5.2.0 used to sit at the top because extract-zip wanted it; with extract-zip gone, execa's 8.0.1 hoists up and cacheable-request keeps 5.2.0 nested. Both versions are still in the tree.

If you would rather not carry the drift in a security PR, say so and I will split it into its own lock-resync PR. I left it in because hand-editing a lock to hide what bun install genuinely does seemed worse than explaining it.

Reachability: this one is real, unlike the rest of LACA-2116

The other eight advisories on this issue live in a docs-site directory that never ships. These five do not. electron is the runtime of a desktop app that Lacy actually runs, so a Chromium or Node vulnerability in it is reachable by definition the moment the app renders untrusted content, and an AI coding agent renders plenty of model output and repo content. The dev-dependency scope on the Dependabot alerts is misleading here. electron is a devDependency only because electron-builder bundles the runtime into the packaged app rather than resolving it at runtime.

I did not try to pin down individual exploit paths for the five, because the conclusion does not change: this is the bump worth doing, and the rest of LACA-2116 is hygiene.

Verification

A typecheck would not have caught an Electron regression, so I booted it.

$ ./node_modules/electron/dist/Electron.app/Contents/MacOS/Electron --version
v42.11.12

bun run build in packages/desktop green. electron-vite built main, preload and renderer, 25.8s.

Then the real smoke test: launched the built app on the new binary and left it up. Raw log:

10:01:12.495  › sidecar connection started { version: 'v1' }
10:01:12.503  › spawning sidecar { url: 'http://127.0.0.1:65210' }
10:01:14.192  › loading task finished
10:01:15.274  › awaiting server ready
10:01:15.275  › server ready { url: 'http://127.0.0.1:65210' }
10:01:15.603  (onboarding) › first launch onboarding completed
10:03:32.702  (utility)    › sidecar exited { code: 0 }

Main process up, sidecar server spawned and reached ready, renderer loaded and ran its own console logging, first-launch onboarding went through, then a clean shutdown with the sidecar exiting 0. No crash, no uncaught exception. The one warning in the log is the Electron insecure-CSP notice, which is pre-existing and only fires in unpackaged dev builds.

bun run typecheck in packages/desktop fails with 286 errors, and that is not from this change. I ran it on the parent commit too and the output is byte-identical after normalizing the temp-dir path prefix. The errors are mostly unresolved @/... path aliases in packages/app. Worth its own issue, but it is a pre-existing red on this fork.

Clears five high advisories from the 2026-09-15 baseline:
GHSA-qmv3-fv6v-rmhq, GHSA-hq2x-r82h-9wj4, GHSA-9qh4-3jw8-366w,
GHSA-gr2m-v5gq-v685 and GHSA-j84w-jfhq-vhvj. The highest fix floor among
them is 42.10.0.

42.3.3 to 42.11.12 stays inside major 42. The app builds and boots on it.

bun.lock also absorbs drift that was already sitting in the repo. The PR
body splits what the bump touched from what any bun install would have
rewritten anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant