Helper tool installation yields "authorizationFailure" error.

[mihajlovicn]

Dear gentlemen,

I'm attempting to run the sample application (Xcode 13.1; macOS 11.6.1) based on the current master branch.
When trying to install the Helper Tool app a "authorizationFailure" error/exception is being thrown (please see screenshot).
What could be the reason?

Personal development signing certificate has been set for both targets.

A short support message is very much appreciated.
Thank you very much in advance. ;)

The log is only showing the following trace:
2021-11-14 16:29:53.584503+0100 Swift Authorization Sample[81859:4601116] MTLIOAccelDevice bad MetalPluginClassName property (null) 2021-11-14 16:29:53.585918+0100 Swift Authorization Sample[81859:4601116] +[MTLIOAccelDevice registerDevices]: Zero Metal services found

Nenad

[mihajlovicn]

./SMJobBlessUtil.py check "/Users/nenad/Library/Developer/Xcode/DerivedData/SwiftAuthorizationSample-druzmcsaxmjyiugpscmrernvsthe/Build/Products/Debug/Swift Authorization Sample.app"
SMJobBlessUtil.py: tool designated requirement (identifier "com.cut2kill.SwiftAuthorizationApp.helper" and anchor apple generic and certificate leaf[subject.CN] = "Apple Development: xxxxxxxxxxx@xxxxxx.com (xxxxxxxxx)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */) doesn't match entry in 'SMPrivilegedExecutables' (anchor apple generic and identifier "com.cut2kill.SwiftAuthorizationApp.helper" and certificate leaf[subject.OU] = xxxxxxxx)

[jakaplan]

This by itself shouldn't be a problem. While they intentionally don't match, that doesn't mean the code signing requirement in SMPrivilegedExecutables doesn't meet the designated requirement for the helper tool. For details see:

SwiftAuthorizationSample/BuildScripts/PropertyListModifier.swift

Lines 87 to 129 in f0c2911

	/// A requirement that the organizational unit for the leaf certificate match the development team identifier.
	///
	/// From Apple's documentation: "In Apple issued developer certificates, this field contains the developer’s Team Identifier."
	///
	/// The leaf certificate is the one which corresponds to your developer certificate. The certificates above it in the chain are Apple's.
	/// Depending on whether this build is signed for debug or release the leaf certificate *will* differ, but the organizational unit, represented by `subject.OU` in
	/// the function, will remain the same.
	func organizationalUnitRequirement() throws -> String {
	// In order for this requirement to actually work, the signed app or helper tool needs to have a certificate chain
	// which will contain the organizational unit (subject.OU). While it'd be great if we could just examine the signed
	// app/helper tool after that's been done, that's of course not possible as we need to generate this requirement
	// *during* the process for each.
	//
	// Note: In practice this certificate chain won't exist when self signing using "Sign to Run Locally".
	//
	// There's no to precise way to determine if the subject.OU will be present, but in practice we can check for the
	// subject.CN (CN stands for common name) by seeing if there is a meaningful value for the CODE_SIGN_IDENTITY
	// build variable. This could still fail because we're checking for *this* target's common name, but creating an
	// identity for the *other* target - so if Xcode isn't configured the same for both targets an issue is likely to
	// arise.
	//
	// Note: The reason to use the organizational unit for the code requirement instead of the common name is because
	// the organizational unit will be consistent between the Apple Development and Developer ID builds, while the
	// common name will not be — simplifying the development workflow.
	let commonName = ProcessInfo.processInfo.environment["CODE_SIGN_IDENTITY"]
	if commonName == nil || commonName == "-" {
	throw ScriptError.general("Signing Certificate must be Development. Sign to Run Locally is not supported.")
	}
	let developmentTeamId = try readEnvironmentVariable(name: "DEVELOPMENT_TEAM",
	description: "development team for code signing",
	isUserDefined: false)
	guard developmentTeamId.range(of: #"^[A-Z0-9]{10}$"#, options: .regularExpression) != nil else {
	if developmentTeamId == "-" {
	throw ScriptError.general("Development Team for code signing is not set")
	} else {
	throw ScriptError.general("Development Team for code signing is invalid: \(developmentTeamId)")
	}
	}
	let certificateString = "certificate leaf[subject.OU] = \(developmentTeamId)"
	return certificateString
	}

[jakaplan]

What happens if you make an Archive build and then "distribute" it as a Developer ID? Does that resulting build also have this issue?

There's probably something going wrong with the code signing, but just from the information you provided I can't tell what it is. If it works when you create an Archive build that might help narrow it down.

[mihajlovicn]

Thank you, Josh.

I'm going to try that with the distribution build, this is a good plan. I currently do not have a Developer plan enrolled for signing/provisioning "Release" builds but this should normally not be required for regular Test runs via Xcode - but maybe this is a problem for SMPrivilegedExecutables.

Greetings to NZ, I wish I could live there. :)

[jakaplan]

Ah that may indeed be the problem. If it turns out this works after you do so, let me know and I'll update the README documentation to reflect this. Apple definitely did not fully document the requirements for SMJobBless (for example there are completely undocumented update eligibility rules based on the helper tool's bundle version number).

If this doesn't work, let me know and I can look into add a menu item to the sample which will display a bunch of diagnostic information. It'd likely take me several days to have the time to work on that.

I've never been to Vienna, I've heard it's lovely!

[mihajlovicn]

I have some findings now.

The PropertyListModifier build script creates the following SMPrivilegedExecutables and SMAuthorizedClients entries in my case:

=== SwiftAuthorziationApp ===

<key>SMPrivilegedExecutables</key>
<dict>
    <key>com.example.SwiftAuthorizationApp.helper</key>
    <string>anchor apple generic and identifier "com.example.SwiftAuthorizationApp.helper" and certificate leaf[subject.OU] = 8xxxxxxx48</string>
</dict>

==== Helper Tool ====

<key>SMAuthorizedClients</key>
<array>
    <string>anchor apple generic and identifier "com.example.SwiftAuthorizationApp" and info[CFBundleVersion] &gt;= "1.0.0" and certificate leaf[subject.OU] = 8xxxxxxx48</string>
</array>

This does not work in my case for whatever reason (see initial problem description).
I'm not enrolled in a Developer plan for actual provisioning of release stuff. I have a Team ID for for automatic signing/provisioning of "Development" builds.

After running the SMJobBlessUtil.py setreq command from the original apple example, the plist entries get "fixed" to:

=== SwiftAuthorziationApp ===

<key>SMPrivilegedExecutables</key>
<dict>
    <key>com.example.SwiftAuthorizationApp.helper</key>
    <string>identifier "com.example.SwiftAuthorizationApp.helper" and anchor apple generic and certificate leaf[subject.CN] = "Apple Development: xxxxxxx@xxxx.at (xxxxxxxx)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */</string>
</dict>

and:

==== Helper Tool ====

<key>SMAuthorizedClients</key>
<array>
    <string>identifier "com.example.SwiftAuthorizationApp" and anchor apple generic and certificate leaf[subject.CN] = "Apple Development: xxxxxxx@xxxx.at (xxxxxxxx)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */</string>
</array>

This change in the plists allows me to install the privileged helper tool via the example app successfully.
What is the obvious difference?:
The SMJobBlessUtil.py setreq uses the "Common Name" from my Apple Development certificate while the OOTB func organizationalUnitRequirement() extracts the "Organisational Unit". I know that the comments of the method extensively elaborate why the "OU" should be sufficient but at least in my case it doesn't work.

@jakaplan, don't feel obliged to "fix" this or so if you do not see some need for your personal self gain (= understanding). It would be cool to understand if this is a general problem or only specific to me. The Archive build did not make a difference.

Best regards,
Nenad

[jakaplan]

@mihajlovicn If you update to the latest commit and run the sample there will now be a "Print Diagnostic Info" option in the menu bar. Mind running that and pasting what it prints out? It will contain the information for the app and helper tool used for the code signing requirements.

[jakaplan]

Thanks for doing that. Unfortunately nothing looks inconsistent between them in a meaningful way.

If you're up for trying out one last thing, it'd be good to know if codesign itself thinks the requirement is met for the app and helper tool signed with your older certificate. To do so run: codesign -vvvv -R="certificate leaf[subject.OU]=6XJ28CNRF7" <path to app/helper tool>

If it satisfies the requirement the last line it prints out will look something like: <path to app/helper tool> explicit requirement satisfied. Otherwise it'll look like: test-requirement: code failed to satisfy specified code requirement(s)

If you're comfortable doing so, could you upload your self-signed app bundle (just zip it up first) with the original certificate? I'll take a deeper look as my time permits. I have a few other theories, but they're all increasingly less likely and don't want to use up too much of your time particularly since it's now working for you.

[amomchilov]

This could be worth contacting apple about, or at least posting on their forums.

[mihajlovicn]

Hm... interesting:

With the old certificate where it's not working:

codesign -vvvv -R="certificate leaf[subject.OU]=6XJ28CNRF7" 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 '6'

codesign -vvvv -R="certificate leaf[subject.OU]=6XJ28CNRF7" com.example.SwiftAuthorizationApp.helper
error: invalid or corrupted code requirement(s)
Requirement syntax error(s):
line 1:29: unexpected token: =
line 1:30: expecting EOF, found '6'

With the new certificate/new Developer ID:

codesign -vvvv -R="certificate leaf[subject.OU]=N9VJP85R3H" Swift\ Authorization\ Sample.app
Swift Authorization Sample.app: valid on disk
Swift Authorization Sample.app: satisfies its Designated Requirement
Swift Authorization Sample.app: explicit requirement satisfied

codesign -vvvv -R="certificate leaf[subject.OU]=N9VJP85R3H" com.example.SwiftAuthorizationApp.helper
com.example.SwiftAuthorizationApp.helper: valid on disk
com.example.SwiftAuthorizationApp.helper: satisfies its Designated Requirement
com.example.SwiftAuthorizationApp.helper: explicit requirement satisfied

@jakaplan , send me an ping mail to "nmradosin@gmail.com" and i'll respond with the zip.
By self-signed app bundle you mean the ziped content at: /Users/xxxxx/Library/Developer/Xcode/DerivedData/SwiftAuthorizationSample-druzmcsaxmjyiugpscmrernvsthe/Build/Products/Debug?

[jakaplan]

Have sent you an email. I don't need the everything that in Debug folder, just the Swift Authorization Sample.app is sufficient. All I meant was because an app bundle is a folder not a file, it'll need to be zipped in order to send it.

[mihajlovicn]

Have sent you an email. I don't need the everything that in Debug folder, just the Swift Authorization Sample.app is sufficient. All I meant was because an app bundle is a folder not a file, it'll need to be zipped in order to send it.

Sure Josh, got the point. I've created a archive build, zipped it and sent it out.

[amomchilov]

Just to chime in: I don't have a paid Apple developer account either, but it still works just fine for me.

[mihajlovicn]

hi Alexander,

thank you for supporting. ;)

can you maybe show your setup of the Signing configuration and Build Settings in this regard?

BR, Nenad

[amomchilov]

I used the "levels" view, but here it is:

[jakaplan]

I'm pretty sure I figured out what was wrong and fixed it. See #8 for details.

[mihajlovicn]

Super, i'll give it a try this week.
Thank you very much.

[mihajlovicn]

yes, it works now OOTB. ;)
thank you very much.