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

Nobody has claimed this yet.

# 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\\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:

```js
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.

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.

Written by the indexing model from the issue text.