It turns out you can't do that from an Admin role. I kept looking at the output of the security command and seeing the older bundle ID showing up for com.apple.developer.driverkit.userclient-access., which was not the updated bundle ID I was developing now.
FYI, this is one of the pitfalls of manual codesigning, as automatic codesigning will not allow that. That's actually the biggest issue with manual codesigning- it allows you to force configuration that won't actually work, so unless you understand EXACTLY why automatic is failing, you can easily end up replacing an error at signing with a different error somewhere "else".
First, I had changed the bundle ID of my dext to what it "should be", after learning that the bundle ID ought to be an extension of the "owning" application's bundle ID.
This is common practice and what Xcode does by default, but I don't believe the system actually requires it, as it needlessly restricts/complicates what's possible without any real benefit. It's been awhile since I've specifically tested this, but it's definitely possible to create an app that doesn't follow this requirement and I believe it will work fine.
Your Team Agent must request DriverKit entitlements and know in advance the bundle ID of the dext you intend to create.
That is not correct, at least not for DEXT creation itself. I think there were a few early approvals that were tied to specific bundle IDs and there may be special cases where we still do this, but it's NOT the normal practice. The standard approach is that your team is granted the entitlement and can add that entitlement to any bundle ID it wants to.
What IS true:
That's how the provisioning profile (2) from the developer portal knows the bundle ID of the dext that your application wants to create a user client for. Having this more clearly documented would be helpful.
...is that the user client entitlement IS tied to a specific bundle ID.
Moving to your next post:
Once that's completed, you still need to create the Identifier to be used, by going to Identifiers and creating one that matches.
Xcode 15 & 16 will do all of this through it's capabilities section, both creating the bundle ID and enabling the entitlement.
...finally under Additional Entitlements there is a drop-box to select DriverKit and System Extension Template for <TeamID> Mac Dev ID profile / Mac Direct Dist Profile (yours may not be named this, but mine is).
This step is not necessary and will not exist for many developers. The UI above is the original process used to "attach" managed entitlements to specific bundle IDs and was actually replaced by the "Additional Capabilities" tab you used above. You do not need to do so and it's effect will either:
-
Neutral, as the system should be smart enough to compare the existing entitlement set (configured through "Identifiers-> Additional Capabilities") and ignore any duplicates.
-
Harmful, as it will allow you to add entitlements to the profile that aren't configured on the identifier. That will then cause problems later, particularly with automatic codesigning.
Order of steps to produce distributable software:
...
Choose Manually manage signing
Again, just to be clear, manual codesigning is ONLY required here due to bugs in Xcode 15. Beyond that, in Xcode 16 is is possible to complete this ENTIRE process without accessing the portal at ALL. Xcode 16's capability interface will create and configure the app record on the developer portal and automatic codesigning will sign thing properly.
Use notarytool and staple to complete the notarization process
Xcode 16 (and I think 15) will also handle notarization.
I know that I do not have DriverKit UserClient Access selected in the Xcode Project -> Target -> Signing and Capabilities selection for either the hosting application or the client only application. This seems to be in keeping with Kevin Elliot's example, and the current situation is working for me, perhaps because the dext is set to "allow any UserClient Access"?
This part is complicated as there are multiple, different, mechanisms at work. Starting with the DEXT side:
-
By default, the initial connection system only allows connection requests from processes that are signed by the same Team ID as the DEXT. The "allow any UserClient Access" entitlement overrides that behavior allowing the "request" from any process. If "your DEXT" only talks to "your app/processes", then you don't need any entitlement to allow.
-
I used the term "request" because the DEXT itself has complete, dynamic control (at runtime) of what it actually accepts connections from. Note that I really do mean "complete and dynamic". If you want to create a DEXT UserClient that only accepts every other request on Tuesdays, that is entirely possible. This is a complicated topic on it's own so if you want to discuss that, lets start a new thread on that subject.
Moving to the app/process side, the system ALSO restricts the ability for user processes to connect to DEXT/KEXTS.
-
"com.apple.developer.driverkit.userclient-access" is the direct entitlement that restricts this. It says "the app with this entitlement can connect to this DEXT bundle ID".
-
This restriction system is part of app sandbox system, so a non-sandboxed app can attempt to connect to "anything".
-
Again, this ONLY controls what the user space process can "attempt". An app can be allowed to connect (either of the two factors above) but still fail to actually create a working user client (because of 1 or 2 above).
This seems to be in keeping with Kevin Elliot's example, and the current situation is working for me
I suspect your app isn't sandboxed.
It is unclear what a Developer Team needs to do when the team must deploy multiple dexts - it seems like the system is built for a single dext authorization (see above post where the Team Agent must register the dext bundle ID) - how would a team select between different dexts
This is a complicated topic as well, so kick off another thread if you really want to dig into it. However, in brief:
-
DEXT (just like KEXTs) can basically be "arbitrarily" complex objects. In many cases, the simplest option is to simply ship a single DEXT that supports multiple devices/configuration.
-
The "com.apple.developer.driverkit.userclient-access" entitlement is an array, so it can contain multiple bundle IDs when the same app needs to talk to multiple DEXTs.
it seems that an installer package is still the best option for distributing the host application
You can do that, but my own preference would be for the app to:
-
Attempt the installation.
-
If it fails, check it's location and tell the user if they need to move the app.
Attempting first covers issues like policy changes on our side or more complex configurations that were created or overlooked.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
