“codesign”

OK, so for some reason, the provisioning profile includes the USB entitlement for vendorID= and I thought because I requested a specific vendor id that I only get that. So after putting into the vendor id field in my USB entitlement in Xcode, they now match, and it works. Strange.... These are the development only entitlements. See this forum post for a detailed run-through of the codesigning side of this. In terms of the matching side of this: The comments feature of the forums is not particularly useful, so please post a complete copy of your IOKitPersonalities dictionary, posted using the code option (which makes it easy to copy out). I have a rundown of the matching and loading process here, so please start by reviewing and validating your DEX against that. That document specifically covers this: Should I set something else for IOClass if my driver does bind to USB interfaces and takes care about exposing them as USB serial devices to the os? I currently have IOClass=IOUserService Also mentioned

Experiencing the same issue here — native macOS (Swift/SwiftUI) app with Sparkle.framework, signed with Developer ID Application certificate using --options runtime and --timestamp on all binaries. We've submitted 12+ times over the past two days, both from local notarytool submit and from GitHub Actions CI. Two early submissions eventually came back Invalid (Sparkle nested binaries needed proper bundle-level signing rather than file-level). After fixing that, codesign --verify --deep --strict passes cleanly on every binary in the bundle. But every submission since the fix — about 10 of them — has been stuck at In Progress indefinitely. We're using App Store Connect API key auth (--key / --key-id / --issuer), and the submissions upload successfully with valid submission IDs. They just never resolve. Team ID: 9UT54V24XG Would appreciate any guidance or if someone from Apple could take a look at our queue. Happy to provide submission IDs if that helps.

I can’t really help you with MDM stuff. If you need help in that space, you can try over in Business & Education > Device Management but you might have more luck over in the Apple Support Community, run by Apple Support, and specifically in the Business and Education topic areas. However, I can help you with this: [quote='877476022, Leo_Nagano, /thread/815340?answerId=877476022#877476022, /profile/Leo_Nagano'] on that MDM‑managed macOS 14.4 (Apple Silicon) device the app still cannot be launched. [/quote] That sounds less like an MDM issue and more like a Gatekeeper issue. [quote='877476022, Leo_Nagano, /thread/815340?answerId=877476022#877476022, /profile/Leo_Nagano'] codesign -dvv confirms the app is signed with our Developer ID Application certificate and has … [/quote] I see no mention of the App ID (com.apple.application-identifier) and Team ID (com.apple.developer.team-identifier) entitlements. Any app that uses restricted entitlement should be signed with those entitlements because they

Update (MDM‑managed macOS 14.4 device): After some additional testing with our third‑party MDM, the Custom macOS app now does get installed via MDM (the notarized Developer ID PKG is assigned to a group with Install Method = MDM and Auto Deploy, and /Applications/MyProxy.app appears on the target Mac with the expected bundle id and version). However, on that MDM‑managed macOS 14.4 (Apple Silicon) device the app still cannot be launched. Finder shows a generic “MyProxy can’t be opened” error, and the process is killed immediately on launch. The key detail from the system log is that the decision is coming from the ConfigurationProfiles / MDM side rather than from Gatekeeper: taskgated-helper[…]: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles] Disallowing com.myapp.agent.MyProxy because no eligible provisioning profiles found At the same time: spctl --assess -vvv -t exec /Applications/MyProxy.app reports source=Notarized Developer ID. codesign -dvv confirms the app is signed with

It does, and the exception reason tripped me up at first: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4339253248 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 102a3c000-102a40000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/5BD67EC6-39CC-428C-944B-C2E2FCA311B4/.app/ Termination Reason: CODESIGNING 2 Invalid Page Turns put it was likely a problem with an async closure passed to a Combine subject as indicated by the first stack frames: 0 ??? 0x0000000000000000 0x0 + 0 1 0x0000000102edacc8 type metadata accessor for (nonisolated(nonsending) (), ()) + 44 (/:0) 2 0x0000000102edac64 type metadata accessor for PassthroughSubject<(nonisolated(nonsending) (), ()), Never> + 44 (/:0)

It sounds like you’re trying to use Developer ID signing for day-to-day development. That’s something I recommend you avoid. Rather, use an Apple Development signing identity for development. For background on this, The Care and Feeding of Developer ID. Having said that, I can help you debug this specific problem. I recommend that you start out by isolating this from Xcode. If you run these commands, what do you see: % cp /usr/bin/true MyTrue % codesign -s Developer ID Application -f MyTrue Run these from Terminal, logged into the same GUI login session as you’re using for Xcode. If that prints a no identity found message, what do you see when you run this command: % security find-identity -p codesigning Policy: Code Signing Matching identities … 11) ADC03B244F4C1018384DCAFFC920F26136F6B59B Developer ID Application: Quinn Quinn (SKMME9E2Y8) (CSSMERR_TP_CERT_EXPIRED) 12) 3F8BE319780F84EB2E94ABDFA24E8045A0572A7B Developer ID Application: Quinn Quinn (SKMME9E2Y8) 12 identities found Valid ident

Entitlements and code-signing requirements are very different. See the following for more background on each: TN3125 Inside Code Signing: Provisioning Profiles TN3127 Inside Code Signing: Requirements You can use a code-signing requirement to check for an entitlement, for example: % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /Applications/Pages.app … /Applications/Pages.app: explicit requirement satisfied % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /usr/bin/true … test-requirement: code failed to satisfy specified code requirement(s) However, entitlements are tricky to use in this situation because: You can’t create a provisioning profile that authorises a custom requirement. Many of of the popular entitlements are either unrestricted on macOS, or only restricted in that they clear the entitlement-validate flag [1]. Given that, I think maintaining your previous approach makes sense, that is, check for the Team ID and a

Thanks for that dump. Much nicer! My reading of the stuff in your latest post suggests that you’re authorised to use the entitlement but you’re not actually claiming it. Remember that a provisioning profile acts an allowlist. It tells the system what entitlements you’re allowed to claim, but it doesn’t actually claim them. You actually claim entitlements in your app’s code signature. Note To learn more about how this works, see TN3125 Inside Code Signing: Provisioning Profiles. I usually debug problems like this by first confirming the nature of the problem: Instead of sending my app directly to App Store Connect, I export an archive. For example, when using Xcode’s organiser window I click Distribute App and then follow the Custom > App Store Connect > Export workflow. I then upload that archive using Transporter. Presuming that reproduces the problem, I unpack the archive by hand. See Unpacking Apple Archives. I can then dump the profile and the entitlements in the resulting app. The profile dump comm