Pin XPC peer requirement beyond Team OU (cdhash or cert OID)

[hakaru]

From Codex security audit (2026-05-04) — POLISH, LOW severity.

`Shared/CodeSigningConfig.swift:20-28` constructs `xpcClientRequirement` to require:

```
identifier "com.macslowcooker.app" and anchor apple generic and certificate leaf[subject.OU] = "K38MBRNKAT"
```

Any app signed with the same Team ID and bundle identifier `com.macslowcooker.app` can connect. There's no distinction by certificate type (Mac App Store vs. Developer ID), specific cdhash, or OID.

Risk profile

• For most maintainers this is fine — Team OU is sufficient identity.
• For a Mac App Store release, an external attacker would need to clone the Team certificate (extremely unlikely).
• For Developer ID + notarization, a maliciously-modified-but-resigned bundle from the same developer is the residual risk.

Mitigations to consider

1. Require `certificate leaf[field.1.2.840.113635.100.6.1.13]` (Developer ID Application OID) to refuse Mac App Store-signed peers, or vice versa.
2. Pin a specific cdhash (only feasible if release builds are pinned to a known hash, awkward for development).
3. Document the current trust model in CONTRIBUTING.md so contributors understand the boundary.

Probably (3) is enough for a personal-use OSS project. (1) makes sense if the app is ever Notarized + distributed broadly.

[hakaru]

Documented in 1ff5770 — added a Security model section to CONTRIBUTING.md explaining the Team-OU trust boundary, what forks need to do, and noting that a future notarized release may want to additionally pin the Developer ID Application certificate OID. The pin itself stays open for if/when distribution scope changes.

[hakaru]

Reopening — only the documentation half of this issue was addressed in 1ff5770 (CONTRIBUTING.md "Security model" section). The actual cdhash / Developer ID OID pin remains unimplemented and should land before any notarized public release.