Pre-check and notarization fail due to misinterpreted spctl failure
PatTheMav opened this issue · comments
While trying to get an app bundle notarized today, I noticed that xcnotary aborts the process 100% of the time as the pre-check fails in all cases.
This seems to be due to spctl always exiting with a non-zero return code when checking a non-notarized bundle due to the following error:
source=Unnotarized Developer ID
This is an expected error however, as the bundle is supposed to be unnotarized by that point. xcnotarys error message is also confusing, as it suggests the bundle includes unsigned binaries or the bundle is not signed with a developer ID cert, but a assessment run via codesign -vvv --deep --strict BUNDLE.app showed all binaries had been correctly signed.
Thanks for the report. How are you building/signing your bundle so that I can repro? I'm getting this using my test bundle:
$ spctl -a -t exec -v correctly_signed.app
correctly_signed.app: accepted
source=Developer ID
May need to make this check less strict.
You can check out the code signing part here: https://github.com/PatTheMav/obs-studio/blob/6b548ee21a6e5cf7db9f61383ddb31c82aee9e07/CI/full-build-macos.sh#L301
It's part of a bigger build process for OBS-Studio. The project is set-up via CMake and compiles without Xcode, necessary frameworks are copied to the bundle and then all Frameworks, plugin libraries and dynamic libraries have their paths fixed and are codesigned with the --deep switch.
As you can see the current code uses Apple's own CLI tools to notarize, which finish successfully.
Thanks. I see. Oddly, I am having a hard time reproducing this even with a plain-built bundle (no xcodebuild, just running a bunch of codesigns similar to your script).
To be sure, is spctl -a --type exec -v Foo.app what you used to confirm the xcnotary error?
I can actually get "Unnotarized Developer ID" if I specify --type install but that one does not appear to be suitable for app bundles. (Post from eskimo@Apple here.)
Since the precheck is for informational purposes only, I'm not too against just whitelisting "source=Unnotarized Developer ID" for that particular command, but would be more confident with a repro.
So I've re-built the app today and went through the steps as implemented in the script. Here are the check-results (via spctl -a --type exec -v ) at different steps:
Before code signing
BUNDLE.app: rejected
source=no usable signature
After code signing with the "Developer ID Application" identity
BUNDLE.app: rejected
source=Unnotarized Developer ID
But searching online for this issue, I believe the issue does not lie with the code signing, but with my developer ID itself:
I just joined the Apple Developer program, so I am a "new" developer and for my developer ID all applications need to be notarized to pass the Gatekeeper checks. Bundles signed with "older" developer IDs still fall under a grace period in which their binaries do not have to be notarized.
My binaries all need to be notarized however, so of course Gatekeeper will always fail on any binary not notarized.
The spctl fail is - as such - expected behavior for more recent developer identities. Once all developer IDs fall under this requirement, spctl will fail in all cases before notarization. At least that's how I understand it.
Ah-ha. I see now: "Beginning in macOS 10.14.5, software signed with a new Developer ID certificate..." (Apple docs).
Going to allow both versions of the output in this case. Thank you for tracking this down!
Fixed in v0.4.0