DriverKit: embedded.mobileprofile has the wildcard USB Vendor ID instead of my assigned Vendor ID

Hi,

First off, a bit of background:

1. The "*" value is used as a wildcard value, meaning "match anything" (in this case, any vendor ID). Note this does NOT mean that your drive will actually load/match against "any" device. DriverKit code signing restricts what your DEXT is eligible to match with, but the IOKit matching system is what controls what you'll ACTUALLY match with.

2. The "wildcard" entitlements are how the "DriverKit < > (Development)" variants are able to match against "any" device, however, they're also what's causing this problem:

my binary fails validation when trying to upload it to the store for distribution

Unfortunately, Xcode 15 has some issues with DriverKit signing (r.124720643). It doesn't understand the difference between the development entitlements and the production entitlements, so it ends up using the Development variant "everywhere". That then breaks when you try to export builds.

Here is what recommend:

-For development purposes, automatic code signing. That works fine right now and it isn't worth the trouble of trying to "fix" it.

-As part of these issues, Xcode may replace the specific entitlement value you define with the "*" value. This should only happen if you change your signing configuration, but be aware of the issue and that you may need to reset the value.

-When you export an archived build from the Organizer, "Custom..." as the initial export type, then "Manually Manage Signing" (later in the configuration sequence).

-You'll then specify the specific provisioning profile for each executable, which you'll generate using the developer portal. This article "Create a development provisioning profile" has an overview of that process.

Hopefully that's enough to sort this out for you but if you still need help or run into anything unexpected, I'd recommend opening a DTS tech support incident .

Kevin Elliott
DTS Engineer, CoreOS/Hardware

Kevin, thank you so much for responding. My entire dev team just got together on a video call and spent 3 hours trying everything we could to figure this out. No personal reflection on you but Apple MUST do better. The information you provided above jives with most of what we discovered. The solution for us was to switch to automatic and also change the idVendor value from a String to a Number when moving from an wildcard value to a literal value. This appears to be necessary when putting a real Vendor ID in the entitlements file. This was a lot harder than it should have been.

@statemachinejunkie Can you layout, in a step-by-step way, how you were able to sign the release build of your app containing a DriverKit extension? We're struggling on our team trying to work through this process. We've tried archiving the build, and then resigning on export but it complains that our entitlements aren't set up correctly in the provisioning profile (but we know they are). What kind of provisioning profile are you using to sign the release version of your DriverKit target?

Our process so far:

• Set signing to automatic for the main app and the driverkit targets.
• Archive the build.
• Attempt to "distribute" the archive using the "Custom" option (trying for an enterprise build)
• Attempt to set the profile in the "Select certificates and iOS In House profiles:" step.
• Set the main app to its In House profile.
• Try to set the driver to an In House profile with "DriverKit" and "DriverKit USB Transport - VendorID" entitlements

And that's where we get stuck. Setting the DriverKit target to the In House profile causes it to throw errors about not being set with the correct entitlements. I'm assuming this has to do with the fact that the entitlements plist is using the wildcard "*" instead of a proper vendor id. But when I try to Archive using the correct vendor ID it throws errors about the dev profile not having the correct entitlements.

Any help would be greatly appreciated. Thanks!

A bit of a late reply on this, but I have a few things to share:

1. As far as I can tell Xcode 16 has fixed all of these issues. Set codesigning to "automatic", configure your capabilities in Xcode, and it signs everything exactly the way it should. I haven't specifically tested enterprise distribution (I don't have an account of that type "at hand"), but the automatic flows have worked perfectly for Developer ID and Mac App Store Test Flight. If it's all possible, I think building and signing with Xcode 16 is the easiest solution to all this.

2. If you must use Xcode 15.4, then you need to be very careful about he exact flow involved.

You're right that this is the underlying issue:

I'm assuming this has to do with the fact that the entitlements plist is using the wildcard "*" instead of a proper vendor id.

The wildcard value is why the development profiles can work with "everything", which is also what breaks distribution signing. Here is what you can try to resolve this:

• I'm not sure how this stands in Xcode 15.4 (I don't have a machine at hand to test this), but Xcode has allowed you to specify a specific entitlement value in your Info.plist while still using the development profiles. However, it's also had a tendency to switch the entitlement value back to *, breaking things again. The last time I specifically tested this, I was able to archive a build in that state (exact plist, wildcard dev profile), which then allowed me to use that manual export flow.

• If that doesn't work, then you can try switching your Developer and Release signing configurations to "Manual" and then specifying specific provisioning profiles for them. In theory, that should let you archive the build and then export using the "Custom" signing flow above.

• If THAT doesn't work, then the final option is to bypass the archive process and generate the build yourself. If you manually set the release configuration of all components to the correct provisioning profile, then the final output should be a properly signed Enterprise build. Archiving exists so that you can export multiple signing variations of EXACTLY the same build object and to simply the "back end" process (submitting builds, etc). It doesn't actually sign things "differently", so it's not actually required to generate any specific build variation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware