chore(desktop): upgrade Electron 35 → 43 (Chromium 150, Node 24) - #3478
Merged
Conversation
Electron 35's last release was 2025-08-19 and only the latest three majors are supported, so we were running an EOL Chromium 134 with ~11 months of unpatched CVEs. 43 brings Chromium 150 / Node 24.18 and a full support window (44 is already in alpha, so 41 would have aged out immediately). - rebuild better-sqlite3 against the new ABI (148) for dev and packaging - node-pty ships matching prebuilds, no rebuild needed Electron only: no entitlements, no configureWebAuthn, no passkey work. The previous 41 attempt bricked the signed app by adding the restricted keychain-access-groups entitlement without a provisioning profile; that is deliberately excluded here.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
![diff-warden[bot]](https://avatars.githubusercontent.com/u/118544361?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warden security clearance: clear. No new security issues found in this diff (f28b1bdad12a50ecaad428b57ad4079c435ed5a9). Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
benjaminshafii
pushed a commit
that referenced
this pull request
Aug 5, 2026
…ing releases (#3561) Since the Electron 35->43 upgrade (#3478) every Linux electron build fails: apps/desktop moved to better-sqlite3 ^13 but apps/server still pinned ^12.11.1, and electron-builder rebuilds every copy of the module it finds in the workspace. v12 compiles against raw V8 headers, which GCC rejects under Electron 43 (v8config.h "expected identifier before __attribute__"), so all six electron-linux-* variants have been red since v0.18.13. Converge apps/server on better-sqlite3 ^13.0.2 (same as desktop). v13 is built on N-API via node-addon-api, so it no longer compiles against V8 headers at all - immune to this class of breakage. Server usage is plain prepare/get/readonly, unchanged across v12->v13. Also mark aur-publish continue-on-error: v0.18.14's rerun failed only because aur.archlinux.org was down for maintenance; a community-channel outage should not mark an otherwise-published release run as failed. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Electron only. No passkeys, no entitlements, no
configureWebAuthn.Why
Electron supports only the latest three stable majors (currently 43, 42, 41). Electron 35's last release was 2025-08-19, so we've been shipping an EOL Chromium 134 with ~11 months of unpatched CVEs — in an app whose job is browsing arbitrary pages in-process.
Went to 43, not 41:
44.0.0-alpha.9already exists, so 41 would have aged out of support almost immediately. 43 gives a full runway.Deliberately excluded
The previous Electron 41 attempt (#3459) bricked the app and was reverted: it added the restricted
keychain-access-groupsentitlement for Touch ID with no provisioning profile, so macOS AMFI SIGKILL'd the signed app at exec (exit 137, before any JS) while every check went green. This PR adds no entitlement, nowebauthn.mjs, noconfigureWebAuthn, and no signing metadata. Verified absent by grep over the diff. Touch ID can come later, gated on a real provisioning profile.Changes (5 files)
^35.0.0→^43.2.0(caret kept, matching prior convention, so 43.x security patches are picked up)@electron/rebuild+ arebuild:electron-nativescript;npmRebuildat packaging time —better-sqlite3needs rebuilding for ABI 148,node-ptyships matching prebuildsVerified from the actual bundles:
LSMinimumSystemVersiongoes 11.0 → 12.0. Anyone on Big Sur will no longer be able to run OpenWork. Please confirm that's acceptable before merging.Verification
pnpm installpnpm typecheckpnpm --filter @openwork/desktop typecheck:electronpnpm --filter @openwork/desktop testcheck:electronreadyState: completeover CDPRuntime confirmed: Electron
43.2.0, Chromium150.0.7871.129, Node24.18.0, ABI148, N-API10.Native modules in-Electron and packaged: SQLite returned
{electron_major: 43}; PTY printedelectron-pty-ok, exit 0. Packaged.nodebinaries are arm64 Mach-O includingdarwin-arm64-148.The launch gate is the check from #3472 — the one that would have caught the #3459 disaster. Run locally here because #3472 isn't merged yet (it touches
.github/, so Warden Clearance deliberately won't self-approve it and it needs a human review).Breaking-change audit (v36 → v43)
main.mjs:2303setsplugins: true. A real packaged PDF kept the same discovered CDP page target; nothing depends on a separate PDF WebContents.UNNotification" — packaged app emitsshowcorrectly. Note: unsignedpnpm devnow logs aUNErrorDomainfailure, i.e. notifications don't fire in unsigned dev builds. Documented upstream behaviour, packaged builds unaffected, but developers should know.electronno longer self-downloads via postinstall" — lazy download works; no postinstall reliance.defaultPath— accepted, no prior-directory contract in the code.Unproven
Windows and Linux packaging/runtime, Intel macOS, Developer ID signing + notarization, and updater distribution. Given the blast radius I'd suggest an alpha build before this reaches everyone.