I have a DriverKit system extension (dext) that uses PCIDriverKit. I would like to get the build environment straightened out to successfully distribute the dext and associated software to end users.
There are three types of software involved:
- The Dext-hosting application - this is the application that must be installed to /Applications/, and will perform the registration of the dext. The dext is deployed "within" this application, and can be found in the /Contents/Library/SystemExtensions folder of the app bundle.
- The dext itself - this is the actual binary system extension, which will be registered by its owning application, and will operate in its own application space independent of the hosting application.
- Additional applications that communicate with the dext - these are applications which will connect to the dext through user clients, but these applications do not contain the dext themselves.
There are multiple locations where settings need to be exactly correct for each type of software to be signed, provisioned, and notarized properly in order to be distributed to users:
- developer.apple.com - where "identifiers" and "provisioning profiles" are managed. Note that there are differences in access between "Team Agent", "Admin", and "Developer" at this site.
- Xcode project's Target "Signing & Capabilities" tab - this is where "automatically manage signing" can be selected, as well as team selection, provisioning profile selection, and capabilities can be modified.
- Xcode project's Target "Build Settings" tab - this is where code signing identity, code signing development team, code signing entitlements file selection, Info.plist options and file selection, and provisioning profile selection.
- Xcode's Organizer window, which is where you manage archives and select for distribution. In this case, I am interested in "Developer ID" Direct Distribution - I want the software signed with our company's credentials (Team Developer ID) so that users know they can trust the software.
Choosing "automatically manage signing" does not work for deployment. The debug versions of software include DriverKit (development) capability (under App ID configuration at developer.apple.com), and this apparently must not be present in distributable provisioning. I believe this means that different provisioning needs to occur between debug and release builds?
I have tried many iterations of selections at all the locations, for all three types of binaries, and rather than post everything that does not work, I am asking, "what is supposed to work?"
Stepping back for a moment, I think it's important to understand what's actually going on here. The starting point here is that there are two sets of data at work here:
- (1) Your Xcode project has a set of data about your app, particularly the entitlement list, which are embedded in the codes signature of your app. That data can actually be viewed with the command:
codesign -dvvv --ent :- <path>
- (2) The developer portal has a set of data about apps bundle ID, particularly the entitlement list, which is used to generate a provisioning profile which will be embedded inside your apps bundle. That data can actually be viewed with one of the following commands*:
*iOS and macOS use slightly different names and locations, a fact which is annoying when you jump back and forth between platforms. I wrote a script years ago which simply tried all 4 possibilities and am now working hard to not remember which is which.
security cms -D -i <path>/embedded.mobileprovision
security cms -D -i <path>/embedded.provisionprofile
security cms -D -i <path>/Contents/embedded.mobileprovision
security cms -D -i <path>/Contents/embedded.provisionprofile
All of the issues here boil down to "the data in those two files doesn't match". That leads to the difference between "Automatic" and "Manual":
-
Automatic-> Xcode will interact with the dev portal, adjusting the dev portal configuration (if it can) and generating/downloading provisioning profiles as needed.
-
Manual-> Xcode will (try) use whatever provisioning profiles you tell it to.
What's changed over time is Xcode's involvement with "adjusting the dev portal configuration". Originally, it didn't really do ANY adjustment. You'd configure the data on the Dev Portal and Xcode would use that data. Between Xcode v14 -> v16, Xcode expanded it's role, with the goal being that Xcode would be able to handle "all" of this configuration. That evolution is also what made Xcode 15 so problematic for DEXT. Xcode 15 added support for configuring managed capabilities (which is what DEXTs rely on) but it DIDN'T properly handle the particular configuration DEXTs use.
The key point here is that manual shouldn't actually "different" than automatic in an fundamental way, as all automatic should be generating exactly the same profile manual would.
That leads to the errors you're seeing. First off, this one:
- There is a problem with the request entity - You already have a current Developer ID Application Managed (with Kext) certificate or a pending certificate request.
I don't know what's causing that, but I don't believe it's directly related to this issue. I suspect it's a side effect of how your archive was originally signed and will self correct once other issues are resolved.
That leads to the other two errors, which are actually the same underlying error. First the manual error:
Profile doesn't match the entitlements file's value for the com.apple.developer.driverkit.userclient-access entitlement.
In other words, you pointed Xcode at a provisioning profile ("2") which didn't match apps signing ("1") configuration. You were actually on the right track here;
there is no place to declare that in the developer portal when making the provisioning profile.
Historically, the portal added a mechanism that could artificially "inject" a single "chunk" of entitlement data into the profile being generated. This was a poor solution that didn't scale which is why we replaced it with the right approach, which is to manage all capabilities in a single place (the App ID).
That leads to this error:
- No profiles for 'com.company.AppName' were found - Xcode couldn't find any Developer ID provisioning profiles matching 'com.company.AppName'.
This could be phrased better, but the issue here is the same as the manual case. That is, the configuration on the portal doesn't match the configuration your app was signed with, so Xcode can't/won't use that profile.
Somewhat ironically, the easiest way to fix these issues is the same in Xcode 15 and 16. Turn on automatic codesign'ing and configure the entitlements you need in the Capability interface. If you're using Xcode 15 that interaction may look pretty broken, as some of the capabilities you add will end up adding two entries in the capability section when there should only be one. That behavior is the visible symptom of Xcode 15s issue with DEXT. It's correctly enabling the entitlement on the portal, but it doesn't understand that the entitlements "collide", so it ends up mishandling profile generation.
The key point is that you shouldn't try to fix archive signing issues at the archive level, you need to move "back" to the earlier archive and fix in there.
Once the portal is corrected:
-
Xcode 16 should handle everything with automatic signing.
-
In Xcode 15, you need to manually generate provisioning profiles which you'd then select during export.
One tip I've found helpful on the manual provisioning side. On a machine that's been used for a long time, I've seen profiles "build up" to the point where it becomes very difficult to pick the right profile. These profile files are actually located in
~/Library/Developer/Xcode/UserData/Provisioning Profiles/
...and you can move/delete them to clear out the "cruft" so you can be sure it's doing the right thing.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
