Hi there,
We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see:
could not insert bundle at <private> into manager: <private>
As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad.
This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build.
We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight.
What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities.
The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details.
If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent.
Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+).
We've been battling this issue for months on and off, so would appreciate some help.
This same error message came up while I was investigating a different issue and one specific thing that you should check is what the build number in Xcode is and, more specifically, make sure that it's 4 characters or less (r.149205067). Xcode uses "CFBundleVersion" to store the build number which, per our document, is officially defined as:
"This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods."
However, KEXTs/DEXTs are obviously critical vectors for attacking the system and because of that they're subject to a much more detailed scrutiny than other components. Critically, much of that validation was written a long time ago and hasn't really changed even though development practices have.
The KEXT enforcement format for versions is both more rigid AND more flexible than the definition above. You can actually see that implementation here:
What it actually enforces is a format like this:
<1-4>.<1-4>.<1-4><1><0-3> -> "1.3.4b12"
(the <1> value is allowed to be a space or the letters <d, a, b, f>)
...which means any build number > 9999 fails because that's more than 4 characters in the first field
FYI, if you look around for what the max length of CFBundleVersion is, you'll find that people have (experimentally) found it to be "18" characters. The format above is where that limit actually comes from.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
