Desktop (macOS): main executable ships Electron's stock LC_UUID, colliding with every other app on the same Electron version #6026

What happened

The packaged macOS app reuses the prebuilt Electron executable unchanged. electron-builder renames it to Maka but does not relink it, so the Mach-O LC_UUID is still Electron 43.4.1's:

$ dwarfdump --uuid /Applications/Maka.app/Contents/MacOS/Maka
UUID: 4C4C4470-5555-3144-A124-518576DD11E3 (arm64)

$ dwarfdump --uuid node_modules/electron/dist/Electron.app/Contents/MacOS/Electron
UUID: 4C4C4470-5555-3144-A124-518576DD11E3 (arm64)

Every app that ships Electron 43.4.1 without rewriting the UUID ends up with the same identity. This is already happening on a real machine. A third-party app (懒猫微服, also on Electron 43.4.1) has exactly the same main-executable UUID:

The helpers (Maka Helper, (Renderer), (GPU), (Plugin)) also keep Electron's stock UUIDs.

Why it matters

On macOS 15+, Local Network Privacy (NECP) identifies a program by the LC_UUID of its main executable. Apple's Local Network Privacy FAQ warns that two programs sharing a UUID can confuse it, and recommends checking dwarfdump --uuid when two apps interact strangely. Possible effects for Maka:

• Granting or denying local network access to one app may silently apply to the other. For example, the user allows 懒猫微服 and Maka's agent commands (curl 192.168.x.x, ssh to a LAN host) inherit that grant without ever prompting, or the reverse.
• Maka never gets its own entry or prompt in System Settings → Privacy & Security → Local Network, so LAN access from the integrated terminal or agent tools fails in ways that are hard to diagnose.
• The collision set changes on every Electron upgrade, so behaviour can change between Maka releases with no code change on our side.

How to reproduce

1. Install a packaged Maka build on macOS (checked with 0.2.0-dev.64.20260929, arm64).
2. Run dwarfdump --uuid /Applications/Maka.app/Contents/MacOS/Maka.
3. Compare it with node_modules/electron/dist/Electron.app/Contents/MacOS/Electron, or with any other installed app on the same Electron version. The UUIDs are identical.

Suggested fix

In an electron-builder afterPack hook, which runs before signing, rewrite the 16-byte LC_UUID payload of the main executable and the helper executables:

• Derive the UUID deterministically, for example UUIDv5 over appId + executable name + arch. Do not randomise it per build. A UUID that stays stable across releases keeps the user's Local Network decision through updates, while a random one would re-prompt after every update.
• Each arch slice needs its own UUID. Universal binaries need one per slice.
• Add a release check that fails if any shipped Mach-O main executable still matches the stock Electron UUID.

Related but separate: Info.plist has no NSLocalNetworkUsageDescription, so even with a unique UUID the prompt carries no explanation.

Environment

• Maka version: 0.2.0-dev.64.20260929 (installed build); repo at f10a74d
• Electron: 43.4.1
• OS: macOS (Darwin 27.0.0), arm64
• Surface: Desktop

References

• Apple Developer Forums, Local Network Privacy FAQ: https://developer.apple.com/forums/thread/737416
• Local Network Access requires binary to have LC_UUID: https://developer.apple.com/forums/thread/761001
• Single Local Network permission entry shown for different applications: https://developer.apple.com/forums/thread/766129

中文版

问题描述

macOS 安装包直接沿用了 Electron 预编译的可执行文件。electron-builder 只把它改名成 Maka，没有重新链接，所以 Mach-O 的 LC_UUID 还是 Electron 43.4.1 原版的：

$ dwarfdump --uuid /Applications/Maka.app/Contents/MacOS/Maka
UUID: 4C4C4470-5555-3144-A124-518576DD11E3 (arm64)

$ dwarfdump --uuid node_modules/electron/dist/Electron.app/Contents/MacOS/Electron
UUID: 4C4C4470-5555-3144-A124-518576DD11E3 (arm64)

所有用 Electron 43.4.1 打包、又没有改写 UUID 的 app，主程序身份都是同一个。真实机器上已经出现了冲突：第三方应用「懒猫微服」同样基于 Electron 43.4.1，主程序 UUID 和 Maka 完全相同：

各个 Helper（Maka Helper、(Renderer)、(GPU)、(Plugin)）用的也都是 Electron 原版 UUID。

影响

macOS 15 起，本地网络隐私（NECP）按主程序的 LC_UUID 识别 app。Apple 的 Local Network Privacy FAQ 明确提醒：两个程序共用 UUID 会让系统混淆；两个 app 出现奇怪的相互影响时，应该先用 dwarfdump --uuid 检查。对 Maka 可能的影响：

• 对其中一个 app 允许或拒绝本地网络访问，可能会悄悄作用到另一个上。比如用户允许了懒猫微服，Maka 里 agent 执行的命令（curl 192.168.x.x、ssh 局域网主机）就会直接沿用这个授权，从头到尾不弹窗；反过来也一样。
• Maka 在「系统设置 → 隐私与安全性 → 本地网络」里一直没有自己的条目，也不会弹出授权提示。内置终端或 agent 工具访问局域网失败时，很难排查原因。
• 每次升级 Electron，跟哪些 app 冲突都会变，所以 Maka 自己的代码没改，行为也可能在版本之间变化。

复现步骤

1. 在 macOS 上安装 Maka 安装包（已在 0.2.0-dev.64.20260929 arm64 上确认）。
2. 执行 dwarfdump --uuid /Applications/Maka.app/Contents/MacOS/Maka。
3. 和 node_modules/electron/dist/Electron.app/Contents/MacOS/Electron，或者本机其他同版本 Electron 应用对比，UUID 完全相同。

修复建议

在 electron-builder 的 afterPack 钩子里（签名之前）改写主程序和各 Helper 可执行文件中 LC_UUID 的 16 字节内容：

• UUID 要确定性生成，比如对 appId + 可执行文件名 + arch 计算 UUIDv5，不要每次构建随机生成。UUID 跨版本保持不变，用户的本地网络授权在更新后才能保留；随机生成的话，每次更新都会重新弹窗。
• 每个 arch slice 需要各自的 UUID，universal 包要逐个 slice 处理。
• 增加发版检查：只要发出去的 Mach-O 主程序还和 Electron 原版 UUID 相同，就让构建失败。

相关但独立的问题：Info.plist 里没有 NSLocalNetworkUsageDescription，所以即使 UUID 唯一了，授权弹窗也没有说明文案。

环境

• Maka 版本：0.2.0-dev.64.20260929（已安装版本）；仓库 commit f10a74d
• Electron：43.4.1
• 系统：macOS（Darwin 27.0.0），arm64
• 端：Desktop