apple-codesign/staple: allow stapling non-App bundles#41
Conversation
e748fcb to
a37a74d
Compare
|
Not sure why the CI run got cancelled, was that something on my end or a transient failure? |
The CI runs were timing out due to a compiler cache permissions issue. I fixed the issue on the |
indygreg
left a comment
There was a problem hiding this comment.
This change looks great! I remember putting that app bundle check in because I was unsure what bundle formats supported stapling and didn't want to over-promise.
Since I initially implemented stapling, Apple has an official notarization API now and error handling for notarization + stapling is more user-friendly. So I'm fine with attempting to staple any bundle with an executable. Plus, in hindsight, it does make sense that any bundle with a main Mach-O (which has a Code Directory - the thing the stapling record identifier is derived from) can be stapled!
In the
staplecommand, there is currently a check to only allow signing App bundles. However, the stapling routine as written appears to work for any bundle which specifies a main executable, such as loadable shared library bundles (like audio plugins, for example). In the event the bundle does not have a main executable,AppleCodesignError::StapleMainExecutableNotFoundis returned as before.I have verified this by testing this PR against a compiled VST3 plugin bundle and comparing the generated
CodeResourcesfile against one downloaded on a Mac usingxcrun stapler stapleon the same bundle. The SHA512 hashes of theCodeResourcesfile as fetched byapple-codesignandxcrun staplermatch.