and I've filed some bugs related to the behavior. FB20212935
FB19451832 FB19450508 FB19450162 FB19449747
Thank you so much, I really appreciate you taking the time to file all of those. DriverKit code signing pushes our code signing infrastructure in ways that nothing else in our ecosystem does and, unfortunately, that means it hasn't really been properly supported by the broader improvements we've made. Filling bugs is a huge help in pushing to improve things.
Moving into specifics and reordering things for clarity:
I can't see a "managed entitlements" section on the account portal.
At WWDC, we revised the portal UI by replacing the:
"Managed Entitlements"-> which showed any managed entitlements you'd been granted.
with:
"Capability Requests"-> which lists the entitlement that a developer can apply for them and links to the application form/process in a single, unified form.
As part of that change, all the entitlement available to your team were merged into the single "Capabilities" tab. In your case, that means you'll find two entries label (less than helpfully) "DriverKit USB Transport - VendorID".
Do I need to request our entitlements again?
No. The process is a bit tedious, but you can get this working.
Starting with what the problem is:
The crux of the problem is that I want to build a driver for USB vendor ID Y. Xcode's well-hidden auto-generated provisioning profile for my driver contains
How Xcode's automatic code-signing "works" is that is simply automates the process of configuring the developer portal and then generating a provisioning profile for that bundle ID. The problem DriverKit exposes is that it doesn't really understand that the same team may have multiple configurations of the same entitlement key, so it "always" picks the first one.
I suspect it worked here:
But I have another, much older project with an auto-generated provisioning profile containing
...because that happened before you were granted the other entitlement.
Moving to the solution part:
Is there a way to inspect what we have already been granted?
The good news here is that the portal itself isn't actually using these names as part of its own implementation. In other words, while the portal is showing the same name for both items it actually handles them as totally unrelated objects and, most importantly, things like their position in the Capabilities list are basically fixed.
That means you can determine which entitlement value a given entry in the capability list provides by:
-
Adding that entitlement to a bundle ID on the portal.
-
Manually generate a provisioning profile for that bundle ID.
-
Download that profile
-
Inspect the contents of that profile to see which of the two values it included.
What can I do to fix this?
The process above will get you a provisioning profile with the correct configuration, which you can then use with manual code-signing.
A second question I have is about the userclient-access entitlement. Are these tied to the bundle ID of the app which claims the access?
No. I actually have a forum post here that breaks down exactly how the user client entitlements work in more detail, but "com.apple.developer.driverkit.userclient-access" is attached to an application and is the bundle ID of the DEXT it targets, which means it cna be attached to "any" app*.
*This does not apply in your case but, speaking to future readers, I have seen cases where the user client entitlement grant was restricted to a particular bundle ID. If that's causing problems, please contact DTS describing the specific issue you're having and including a link to this post, and I'll see if I can have the restriction removed.
...once the entitlement is granted, can I use com.apple.developer.driverkit.userclient-access = { com.mycompany.app1.driver1 } in any of my apps?
Yes, that's how it should work (ignoring the footnote above). However, you would need separate entitlement grants for different drivers/apps, so different apps/drivers would need:
com.mycompany.app1 ->
developer.driverkit.userclient-access = { com.mycompany.app1.driver1 }
com.mycompany.app2 ->
developer.driverkit.userclient-access = { com.mycompany.app1.driver2 }
And another if you wanted an app to talk to both, you'd need:
com.mycompany.MegaApp ->
developer.driverkit.userclient-access = {
com.mycompany.app1.driver1,
com.mycompany.app1.driver2 }
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
