Add local macOS release signing and notarization - #23
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
macOS CI artifacts need local Developer ID signing before they can load in Aegisub with library validation enabled. Add
osx-sign.shto sign a downloaded artifact and atomically refresh its dylib checksum, plusosx-notarize.shto validate and submit a ZIP using a stored Keychain profile. The release ZIP is created only after Apple accepts the submission; failures show the submission status and available notary log.The scripts follow Aegisub's local release process, support custom signing/notary keychains, and require no dependency rebuild. Notarization requires the expected Aegisub Team ID and checks it before submission. ZIP root folders follow the output filename, and publication refuses to overwrite a file created while awaiting Apple. Brief instructions live in
docs/releasing.md. Standalone dylibs and ZIPs do not support stapling.Validation: ShellCheck and local ARM64/Intel Meson tests pass. Both macOS CI jobs run regression tests covering real ad-hoc signing, refreshed checksums, rejection of modified inputs, wrong platforms/teams, and ad-hoc notarization; nested checksums; simulated accepted/rejected/timed-out submissions; and preservation of an output created during notarization. Tests cannot contact Apple's service. Live validation was repeated with the final scripts and the downloaded artifacts from this PR. A real signed dylib was rejected when supplied with the wrong expected Team ID. With the correct team, both ARM64 and Intel dylibs were Developer ID-signed with secure timestamps, Apple returned
Accepted/Ready for distributionwith no issues for both ZIPs, and all packaged checksums verified. The signed ARM64 dylib loaded and rendered through the wrapper inside the existing Developer ID-signed Aegisub release with hardened-runtime library validation enabled, using an isolated test profile.All five hosted CI jobs pass, including both macOS release-script tests and all artifact uploads.