Windows: Smart App Control blocks the app — only the installer is signed, not the binaries it installs

Start in forge.config.js and inspect the maker-squirrel configuration alongside Electron Forge v7's Windows signing support. Check how the existing certificate environment variables are passed, including the Squirrel stub and Update.exe. Done means the packaged executables and DLLs are signed, and the installed artifacts pass Authenticode checks so Smart App Control no longer blocks Logseq-OG.exe.

Windows: Smart App Control blocks the app — only the installer is signed, not the binaries it installs

Summary

The Windows installer is validly signed by Logseq, Inc., but every binary it
installs is unsigned. On Windows 11 with Smart App Control (SAC) enabled,
Code Integrity blocks Logseq-OG.exe at load time and the app cannot start.

SAC has no per-app override — no "Run anyway", no exclusion list, and running as
administrator does not bypass it. The only user-side workaround is disabling SAC
system-wide, which is a poor trade and was historically irreversible without
reinstalling Windows.

Environment

• Logseq-OG 1.0.0, Logseq-OG-win-x64-1.0.0.exe
• Windows 11, build 26200
• Smart App Control: On (enforcing) — VerifiedAndReputablePolicyState = 1

Note: the app installed and ran fine for ~2 weeks while SAC was in Evaluation
mode, then broke with no change to Logseq when Windows promoted SAC to enforcing
(SAC_PreviousState = 2, SAC_EnforcementReason = 1).

What happens

Launching from the Start menu, desktop shortcut or directly does nothing —
no window, no error dialog. Microsoft-Windows-CodeIntegrity/Operational logs
events 3033 and 3077 on every attempt:

Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\explorer.exe)
attempted to load \Device\HarddiskVolume3\Users\<user>\AppData\Local\Logseq-OG\Logseq-OG.exe
that did not meet the Enterprise signing level requirements or violated code integrity policy
(Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}).

Signature audit

Get-AuthenticodeSignature on the shipped 1.0.0 artifacts:

Binary	Status
Logseq-OG-win-x64-1.0.0.exe (installer)	Valid — CN="Logseq, Inc.", timestamped
%LOCALAPPDATA%\Logseq-OG\Logseq-OG.exe (Squirrel stub)	NotSigned ← blocked
%LOCALAPPDATA%\Logseq-OG\Update.exe	NotSigned
app-1.0.0\Logseq-OG.exe (Electron main)	NotSigned
app-1.0.0\squirrel.exe	NotSigned
app-1.0.0\ffmpeg.dll, libEGL.dll, libGLESv2.dll, vk_swiftshader.dll, vulkan-1.dll, dxcompiler.dll	NotSigned

(The bundled Git for Windows and Git Credential Manager binaries are signed by
their own publishers and are not the problem.)

Root cause

forge.config.js signs macOS thoroughly but Windows only at the installer step:

packagerConfig: {
  osxSign:     { identity: 'Developer ID Application: Logseq Inc. (K378MFWK59)', ... },
  osxNotarize: { tool: 'notarytool', ... },
  // no windowsSign — packaged Windows binaries are never signed
},
makers: [
  { name: '@electron-forge/maker-squirrel',
    config: { certificateFile: process.env.CODE_SIGN_CERTIFICATE_FILE, ... } }  // signs Setup.exe only
]

osxSign signs everything inside the macOS bundle. There is no Windows
equivalent configured, so maker-squirrel's certificate covers only the
generated installer — the app's own executables ship unsigned.

Suggested fix

Add a windowsSign entry to packagerConfig so the same signing identity
already used for the installer is applied to the packaged binaries before the
maker runs (Electron Forge v7 supports this via @electron/windows-sign). That
should cover the Electron main exe and DLLs; the Squirrel stub and Update.exe
need to be signed as well, since the stub is the binary SAC actually blocks.

This needs no new certificate — just wider application of the existing one.

Why this will affect more users

SAC ships enabled on many new Windows 11 installs, starts in Evaluation mode, and
promotes itself to enforcing once a machine looks clean. Users who installed
successfully will have the app stop launching later, with no error message and no
obvious cause. Signed-but-unsigned-payload Electron apps are hitting this broadly
in 2026 (see e.g. openai/codex#32487, trycua/cua#2118).

Not a tampering report

For the avoidance of doubt, the build I have is authentic — SHA-256 matches
SHA256SUMS.txt for 1.0.0 exactly, and the installer's Authenticode chain is
valid. This is purely about which binaries get signed.

AI disclosure

This issue was prepared with the assistance of Claude Code. The diagnostics it
reports — the Authenticode signature audit, the CodeIntegrity event capture, the
SHA-256 verification against SHA256SUMS.txt, and the forge.config.js
analysis — were all run against a real affected installation on my machine.