[FIX] Re-sign the dev Electron; correct the recorded cause of the malware flag - #23
Merged
Merged
Conversation
- Launching the stock dev binary (node_modules/electron/dist/Electron.app) makes macOS 26 report "Electron.app was not opened because it contains malware" and delete it, so `yarn workspace @subzilla/mac dev` could not start. The download is authentic: it matches Electron's published SHA-256. - scripts/sign-dev-electron.js re-signs it ad hoc under its own identifier before `dev` and `start` launch it, and reinstalls the binary first if macOS has already removed it. Idempotent. - Verified: the same binary that was flagged twice runs and stays on disk once re-signed; `yarn start` boots the app with a clean log. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- #19 blamed an invalid code signature. That was wrong. `codesign --verify` on STOCK Electron always says "code has no resources but signature indicates they must be present" - including 31.0.0, which ran all along - so it cannot be the cause. - What the evidence supports: macOS flags anything still carrying stock Electron 31.7.7's executable code hash (the packaged app once, a pristine checksum-verified Electron.app twice), never stock 31.0.0, and never a re-signed 31.7.7 (7 of 7 launches). Re-signing replaces the CDHash. That Apple blocklists the stock hash because malware ships inside unmodified Electron binaries is inference; the rest is measured. - The fix from #19 (ad-hoc re-signing in afterPack) is still correct and effective; only its stated reason changes. Updated the hook's comment, CLAUDE.md, the mac rule and both skills. - verify-mac-bundle.sh and the release workflow now also fail a bundle that is validly signed but still identifies as stock Electron. Checked with a negative control. Co-Authored-By: Claude Fable 5.1 <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.
Summary
macOS flagged "Electron.app … contains malware" again — this time the untouched development Electron binary. That disproves the cause I recorded in #19, so this PR corrects the record and protects dev mode.
Correction to #19
#19 said an invalid code signature made macOS flag the app. That was wrong.
codesign --verifyon stock Electron always printscode has no resources but signature indicates they must be present— for 31.7.7 and for 31.0.0, which ran all evening without complaint. It is how Electron ships, not something electron-builder broke. I had noticed the 31.0.0 inconsistency at the time and did not run it down.What the evidence supports
Electron.app×2The download is authentic (matches Electron's published SHA-256) and every bundled package is identical to npm, so this is not a compromised dependency. The one consistent discriminator is the executable's CDHash (
5195eea8…stock 31.7.7 vs987eb685…stock 31.0.0), which re-signing replaces.Most likely Apple blocklists that stock hash because real malware ships inside unmodified Electron binaries. That last step is inference — I cannot read Apple's list — but it is the only account consistent with all observations.
The fix from #19 is still correct and effective. Only its stated reason changes.
Changes
scripts/sign-dev-electron.js: re-signs the dev binary beforedev/start, and reinstalls it first if macOS already removed it. Idempotent.yarn startnow boots with a clean log.adhoc-sign.js,CLAUDE.md,.claude/rules/mac-app.mdand both skills.verify-mac-bundle.shand the release workflow now also fail a bundle that is validly signed but still identifies as stock Electron (Identifier=Electron). Verified with a negative control: fails when it should, passes when it should.Worth knowing
🤖 Generated with Claude Code