helper Install Failed.
Closed this issue · 13 comments
build on a fresh git clone,
nothing changed except something like below:
- CODE_SIGN_IDENTITY = "-";
- CODE_SIGN_STYLE = Automatic;
- DEVELOPMENT_TEAM = "";
+ CODE_SIGN_IDENTITY = "Developer ID Application";
+ CODE_SIGN_STYLE = Manual;
+ DEVELOPMENT_TEAM = 1234567890;
+ PROVISIONING_PROFILE_SPECIFIER = "";
but the helper says Install Failed( authorizationFailure ).
App "com.example.SwiftAuthorizationApp" did not pass helper check "com.example.SwiftAuthorizationApp.helper".
When running the app, can you go into the menu and choose "Print Diagnostic Info"? That will print out some helpful information to your Xcode console. If you copy and paste that into this issue I may have a better idea of what's going wrong.
A couple of thoughts before I have that additional information:
- Are you trying to create a production build? I'd expect your
CODE_SIGN_IDENTITYto have a value ofApple DevelopmentnotDeveloper ID Applicationif you're just building normally. - It's possible switching
CODE_SIGN_STYLEfromAutomatictoManualis problematic (I've never tested it withManual), but also have no specific reason to think it is.
change to "Automatically manage signing" and the same failure
the result of "Print Diagnostic Info"
2022-03-21 19:29:03.265016+0800 Swift Authorization Sample[37224:9843272] Metal API Validation Enabled
==============This App=============
CFBundleIdentifier: com.example.SwiftAuthorizationApp
CFBundleVersion: 1.0.0
Common Name: Apple Development: CHAO SONG (6xxxxxG)
Organizational Unit: 4xxxxxxx5
========Bundled Helper Tool========
CFBundleIdentifier: com.example.SwiftAuthorizationApp.helper
CFBundleVersion: 1.0.1
Common Name: Apple Development: CHAO SONG (6xxxxxG)
Organizational Unit: 4xxxxxxx5
=======Installed Helper Tool=======
Helper tool is not installed
Hmm, that's quite odd as the organizational units match or at least I'm assuming they do based on the "x"s you used. (FYI organizational units and common names aren't sensitive information.)
Can you try running the following in Terminal and letting me know what the output is:
codesign -vvvv -R="certificate leaf[subject.OU]=<your organizational unit>" <path to Swift Authorization Sample.app>
Where <your organizational unit> is the true value of what you showed as "4xxxxxxx5" and <path to Swift Authorization Sample.app> is wherever the app is located after building; by default it'll be somewhere within the ~/Library/Developer/Xcode/DerivedData directory.
This command has codesign directly check whether the organizational unit requirement is met.
Is my codesign broken or something escape char error?
~/Library/Developer/Xcode/DerivedData/SwiftAuthorizationSample-dommtsuqivdfdabtnvhcgpcmpxov/Build
❯ codesign -vvvv -R="certificate leaf[subject.OU]=4FJB6F5Z95" Products/Debug/Swift\ Authorization\ Sample.app
error: invalid or corrupted code requirement(s)
Requirement syntax error(s):
line 1:29: unexpected token: =
line 1:30: expecting EOF, found '4'
I think there's something wrong with your Apple issued signing certificate. This sounds very similar to #2 which was resolved when the developer got a new signing certificate.
Could you reply with a zip of your signed sample code? I'll take a closer look at how it was signed and maybe I can figure out more specifically what's going wrong so I can start up a discussion on the Apple Developer forums.
by the way, here is the notarized app which has the same failure
Swift Authorization Sample.app.zip
So I've figured out what's going wrong, but I currently have no idea why this is happening.
Organizational units that begin with a number can't be turned into a valid SecRequirement, while those that begin with a letter can. This is based on the result code from the SecRequirementCreateWithString function. When it fails, the error code is -67052 which is errSecCSReqInvalid.
Concretely:
- This is not a valid
SecRequirement:certificate leaf[subject.OU] = 4PJB6F5Z95 - This is a valid
SecRequirement:certificate leaf[subject.OU] = M8VJP85R3H
These are "made up" organizational units, I have no reason to believe they actually exist.
It sounds weird. Thanks for your patient investigation.
Followed an educated hunch and I think it's correct which is that Apple's security requirements parser fails if the organizational unit is unquoted and starts with a number. I've updated the sample to now always place the organizational unit within quotes as part of the build script.
@chaosong can you update to the latest version of the sample and try again?
Reopening this issue until I get confirmation from @chaosong this actually resolves the issue.
It works! A big thanks!
xcode running
notarized app
Thanks for reporting the issue!