macOS packaging spends most of its time signing Git Credential Manager, which Maka does not use
#3.202 aberto em 18 de ago. de 2026
Métricas do repositório
- Stars
- (1 estrela)
- Métricas de merge de PR
- (Nenhuma PRs mesclada em 30d)
Description
The macOS package job spends most of its wall clock signing binaries Maka never runs.
electron-builder signs every executable under extraResources individually, and each codesign --timestamp makes a network round trip to Apple's timestamp authority. Measured on the bundled Git distribution (node_modules/dugite/git):
| Group | Executables | Size |
|---|---|---|
| Git Credential Manager + its .NET runtime | 219 | 68.9 MiB |
git, scalar, git-lfs, git-http-push, … |
48 | 19.1 MiB |
share/git-core/templates sample hooks |
14 | ~0 |
| Total | 281 | 88 MiB |
78% of the signing work is Git Credential Manager, which Maka does not use — credentials live in its own credentials.json under the 0700/0600 contract in SECURITY.md, and nothing in apps/desktop or packages/* invokes GCM.
During a local macOS package the signing step held at ~0% CPU for over 13 minutes: the cost is not compute, it is 281 sequential network round trips.
Suggested fix: drop the Git Credential Manager tree from what gets packaged (an extraResources filter, or a prune step over the dugite copy before packaging), and confirm git still functions for the operations Maka performs. That removes ~69 MiB from the artifact and roughly three quarters of the signing round trips.
Verified, so the issue does not repeat a wrong guess: I first assumed the cost came from broken hard links duplicating the git binary hundreds of times. That is wrong. Scanning the tree programmatically — excluding symlinks, which is what fooled a shasum spot check, since most libexec/git-core entries are symlinks to git — there are 281 real executables with 274 distinct contents. True duplication is 3 groups totalling 5.1 MiB, so restoring hard links is not the win here.
Related: #3146 already records the ~95 MiB Git Credential Manager / SkiaSharp payload as a size item. This issue is the same payload seen from the packaging-time side, and the fix is shared.