fix(packaging): support non-upstream Developer ID signing - #3372
fix(packaging): support non-upstream Developer ID signing#3372krazybean wants to merge 1 commit into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c25f88c6e3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if [[ "${APP_TEAM_ID}" != "Y5PE65HELJ" ]]; then | ||
| echo "WARN: Skipping CodexBarWidget for local team ${APP_TEAM_ID} (build failed, continuing without widget)." >&2 | ||
| return 0 |
There was a problem hiding this comment.
For every non-upstream team, any xcodebuild failure—not only the managed-sandbox cache error—is converted into success. Thus an ordinary fork release with a widget compilation error, missing dependency, or invalid project can still produce and potentially distribute an app with CodexBarWidget.appex silently omitted; restrict this exception to the explicitly detected smoke-test environment or propagate the failure.
Useful? React with 👍 / 👎.
| echo "WARN: Could not derive team ID from APP_IDENTITY; disabling upstream profile (safe fallback)" >&2 | ||
| if [[ "${APP_IDENTITY}" != *"Y5PE65HELJ"* ]]; then | ||
| # Prevent accidental use of upstream profile/iCloud when team is unparseable | ||
| APP_TEAM_ID="LOCAL" |
There was a problem hiding this comment.
When APP_IDENTITY is otherwise usable for signing but has no parseable parenthesized team and the certificate lookup cannot resolve it, this fabricates LOCAL and embeds LOCAL.com.steipete.codexbar in the app/widget entitlements. At runtime AppGroupSupport.resolvedTeamID prefers the actual team from the code signature, so it requests a different group identifier and the app and widget cannot share their container; derive the real team, omit the group capability, or fail packaging instead.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
P2
|
Codex review: needs real behavior proof before merge. Reviewed September 1, 2026, 8:37 PM ET / September 2, 2026, 00:37 UTC. ClawSweeper reviewWhat this changesThis PR derives a fork signer’s team ID, avoids upstream provisioning for non-upstream signing, adds timestamp retry behavior, and skips the launch smoke check when sandbox execution is denied. Regression provenancePossible regression — probable (reviewed change; failure trace). No predecessor PR is attributed. Merge readiness⛔ Blocked until real behavior proof is added - 9 items remain Keep open: the fork-signing direction is useful, but the introduced error handling can silently ship a fork build without its widget and can generate invalid app-group entitlements when team resolution fails. Priority: P2 Review scores
Verification
How this fits togetherCodexBar’s packaging scripts assemble and sign the macOS app, widget, helper binaries, entitlements, and optional upstream provisioning profile. The resulting bundle is then checked for basic launchability before local distribution or release workflows use it. flowchart LR
A[Packaging configuration] --> B[Signing identity]
B --> C[Team ID and entitlements]
C --> D[App and widget signing]
D --> E[Packaged app bundle]
E --> F[Launch smoke check]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Preserve the fork-safe profile restriction while failing packaging on unresolved team identity and on widget build failures except for a positively identified, explicitly supported sandbox-only case. Do we have a high-confidence way to reproduce the issue? Yes for the introduced defects: source shows that any non-upstream widget-build failure returns success, and an unresolved identity assigns LOCAL before app-group entitlements are generated. A real macOS package/sign/launch trace has not been supplied or executed in this read-only review. Is this the best way to solve the issue? No. The derived-team and upstream-profile restriction are narrowly targeted, but broad widget omission and a fabricated team ID undermine the packaging contract. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 2cac84440c42. LabelsLabel changes:
Label justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Select upstream CloudKit provisioning only for its resolved signing team, and share the resolved bundle ID when deriving app/widget groups. Extracted from #3372. Sixteen actual entitlement/profile-selection configurations, existing signing checks, make check, full 1,028-selection suite and exact-head CI pass. Direct alternate identity discovery remains separate. Co-authored-by: Juanito <krazybean@gmail.com>
|
The resolved-team provisioning mismatch is now fixed on main in #3461 ( The narrower repair also derives app/widget groups from the resolved bundle ID. This PR remains open for the separate direct-identity discovery path. Timestamp fallback, widget omission and sandbox-smoke bypass were not needed for the verified profile-selection defect. |
2 participants
Summary
Allows CodexBar forks to package/sign the app with a non-upstream Developer ID without embedding upstream provisioning or entitlement metadata.
The existing packaging flow assumes CodexBar's upstream signing team and provisioning profile. That works for upstream releases, but a fork signed with a different Developer ID can end up with a locally signed app that still contains upstream team-bound provisioning/entitlement values, which macOS can reject at launch.
What changes
Scripts/profiles/CodexBar-DeveloperID.provisionprofileonly when packaging with CodexBar's upstream team (Y5PE65HELJ).Timestamp fallback
For non-upstream signing only, packaging now falls back to signing without a timestamp if Apple's timestamp service is unavailable.
Upstream (
Y5PE65HELJ) release signing remains strict and does not receive this fallback, so the upstream release path is not weakened.Launch smoke test
The packaged-app launch verification now detects environments where
sandbox-execitself is unavailable/forbidden and skips that sandboxed smoke step in that specific case.The existing explicit:
CODEXBAR_SKIP_LAUNCH_SMOKE=1override remains unchanged.
Normal environments where
sandbox-execworks continue to run the smoke test.Why
This surfaced while testing CodexBar from a fork with a different Developer ID.
The resulting app was correctly signed by the fork's identity, but still contained an upstream provisioning profile/team metadata. Signature verification could succeed while launchd rejected the app at spawn time.
With this change, upstream and fork packaging paths remain internally consistent:
Scope
This PR only changes fork/release packaging behavior.
The Muse provider work that exposed the issue is submitted separately in #3371.