“codesign”

Please file a bug about this. There’s advice on how to gather the necessary info in that error alert, and it’d be great if you attach that to your bug report. Once you’re done, please post your bug number, just for the record When you click the Show Details button in that error alert it shows a bunch of info about what’s causing the error. It’s clearly grumpy about the provisioning profile. However, when you compare the profile’s allowlist and the code signature’s claims, things generally look OK. One thing I did notice is that there’s a bit of a mix up about the type of the com.apple.security.hardened-process.enhanced-security-version entitlement. That’s documented to be a string, and the profile’s allow list uses a string value of *. However, the code signature claims an integer value of 1. I manually re-signed the app to use a string: % cat tmp.entitlements … … com.apple.security.hardened-process.enhanced-security-version 1 … % /usr/bin/codesign --force --sign 09513FD4A03387429F6568048A5F76A743

[quote='806186021, binarytwist, /thread/806186, /profile/binarytwist'] How can I get a provisioning profile that only has the entitlements that I actually need? [/quote] You shouldn’t need to do this. The entitlements in a provisioning profile act as an allowlist. For an in-depth explanation of that, see TN3125 Inside Code Signing: Provisioning Profiles. When you enable the NE capability on an App ID and generate a profile for that App ID, the Developer website includes all NE types supported by the target platform. Hence the presence of url-filter-provider value. However, this is just an allowlist. The entitlements you claim are those in your code signature, and that’s what the Validate App should be checking. [quote='806186021, binarytwist, /thread/806186, /profile/binarytwist'] My entitlement file has [/quote] Your .entitlements file isn’t the source of truth here. It’s source code that acts as an input to the Xcode build system. So you need to check the entitlements on your built binary. Do this: In the X

The Communicating example says in the readme to disable SIP, so which one is right? Technically, we're both right as the old disable SIP flow does still work (at least theoretically). However, the new flow is so much easier that I wouldn't bother with the SIP flow. And the provisioning profile is missing the driverkit.allow-any-userclient-access entitlement. How should I add that? Don't bother, just delete it from your Entitlement.plist. This forum thread outlines exactly how the user client entitlements work and, with that context, what you'll actually end up doing is: In the long run, you'll eventually request the right user client entitlements based on your needs, using the forum post above to figure out which one is right for you. In the short run, you can sidestep the entire problem. Your DEXT will already allow connections from code that's signed by your team and your app can get past its restrictions by either disabling the app sandbox and/or adding the IOKit User Client Class Temporary Exception. See

So, the tl;dr here is that this issue is now resolved. There may be other outstanding issues, but you can now: On a macOS 15 or later host, install macOS 15 or later in a VM. On the guest, log in using an Apple Account in System Settings. And install Xcode. And add your Apple Account to Xcode. And then build and run a Mac app. Even if it uses a restricted entitlement. If you’re interested in how I tested the above, I’ve included a summary at the end of this post. If you’re encountering other issues, please start a new thread with the details. This thread is already long enough |-: If you’re interested in the history, I have a summary of that in this post. That was from 13 Jun 2025. Since then there’s been one critical change, namely that on 9 Oct 2025 we rolled out a Developer website update that fixes the provisioning UDID issue (r. 149209127). And on that note, I think I can finally put this issue to bed. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 +

Can anyone give advice? Thanks a ton! Unfortunately, this is actually the first time I've looked at Building an Audio Server Plug-in and Driver Extension and, to be honest, that is not great sample code. Using darwinup in a shell script is not something any one should actually do. I've already filed a bug on this (r.163226098), but you're going to need to do a bit of work to end up with something reasonable. SO, what I would actually suggest is the following: Start with the sample Communicating between a DriverKit extension and a client app and get it building and running. That's our simplest sample and will let you sort out the basic build and install process. Once that's working, replace the DEXT inside that sample with the DEXT from Building an Audio Server Plug-in and Driver Extension. Once that's done, you'll have an installer app with an embedded DEXT, which is what ALL DEXT need to be shipped as anyway. Shifting to the codesign front: I would be ok for now with the local option, but XCode 16.4

Hi Kevin — thanks for the detailed reply. Quick confirmations We’re already shipping the ES daemon as an app-bundled executable (signed, hardened, notarized). FDA is being granted through System Settings → Privacy & Security → Full Disk Access to the app bundle (per your #1), not to a bare exe. ES entitlement is present; Gatekeeper/SPCTL and codesign checks are clean. What we’re actually hitting (repro matrix) Apple Silicon (M-series) – macOS 15.6: Works. FDA toggles on and persists. ES daemon runs fine at boot. Intel – macOS ≤ 15.5: Works. Intel – macOS 15.6 ONLY: Broken. In Full Disk Access, turning the toggle On either immediately flips back Off, or appears On but flips Off after navigating away and back. When it “looks” On, the ES daemon still behaves as if FDA is not granted. This behavior is consistent across multiple Intel machines and fresh user profiles. Extra notes about launch The daemon is launched by launchd (system domain) as usual. Our installer (run by another LaunchDaemon’s insta

Thanks for your answer. I removed the files you mentioned and get the same positive output from codesign -vv, but it doesn't make any difference regarding the notarization process. I tried using Xcode for the signing, but it seems like it's not compatible with what Qt offers.

Following up with this to clear up some odds and ends: Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement. One thing to be aware of here is that Xcode has a bias in the way it presents codesign errors where it assumes the Entitlement.plist is correct and the profile is wrong. However, in practice that's basically never the case with DriverKit entitlements and tends to lead to a lot of flailing trying to somehow fix the provisioning profile. This error ALWAYS means that the entitlement.plist doesn't match the profile. You fix that by: Changing the Entitlement.plist to match the profile. Changing the actual profile. That means either: Submitting a new request to correct any mistake (this case). IF you have been granted multiple instances of the same entitlement, then you switch to manual profile generation and manual codesigning. See this forum post for more details on that flow. However, the key here is to understand that this: ...ou