You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "sosyz (via GitHub)" <gi...@apache.org> on 2026/10/09 08:38:38 UTC
[I] Desktop (macOS): main executable ships Electron's stock LC_UUID, colliding with every other app on the same Electron version [maka]
sosyz opened a new issue, #6026:
URL: https://github.com/apache/maka/issues/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:
| App | Electron | Main executable LC_UUID |
|---|---|---|
| Maka | 43.4.1 | `4C4C4470-5555-3144-A124-518576DD11E3` |
| 懒猫微服 | 43.4.1 | `4C4C4470-5555-3144-A124-518576DD11E3` |
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 f10a74d8e
- 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 完全相同：
| 应用 | Electron | 主程序 LC_UUID |
|---|---|---|
| Maka | 43.4.1 | `4C4C4470-5555-3144-A124-518576DD11E3` |
| 懒猫微服 | 43.4.1 | `4C4C4470-5555-3144-A124-518576DD11E3` |
各个 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 f10a74d8e
- Electron：43.4.1
- 系统：macOS（Darwin 27.0.0），arm64
- 端：Desktop
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop (macOS): main executable ships Electron's stock LC_UUID, colliding with every other app on the same Electron version [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #6026:
URL: https://github.com/apache/maka/issues/6026#issuecomment-6294603287
take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop (macOS): main executable ships Electron's stock LC_UUID, colliding with every other app on the same Electron version [maka]
Posted by "ggbdpq (via GitHub)" <gi...@apache.org>.
ggbdpq commented on issue #6026:
URL: https://github.com/apache/maka/issues/6026#issuecomment-6295245743
Implemented — PR: https://github.com/apache/maka/pull/6200
Root cause confirmed as reported: the packaged bundle reuses Electron's prebuilt executables, so every Mach-O (main + helpers) ships Electron 43.4.1's own `LC_UUID`.
The fix adds a deterministic `afterPack` hook (pre-signing) that rewrites each executable's UUID payload in place with UUIDv5 over `appId/executableName/cpuType` — byte count and all other bytes unchanged, idempotent, mac-only. Verified against a real fat Mach-O (`dwarfdump --uuid` before/after, exactly the 16-byte payloads differ, size stable) with a python3 `uuid.uuid5` cross-check; full signing/notarized packaging is the one lane that needs CI certificates, noted in the PR verification table.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org