“codesign”

Hi there, Sorry for a late reply and the issue you're encountering. In the newest versions of Instruments we've added better error handling, which should guide you through the steps and what to check (perhaps if you expand error in the popover it should already tell you). Binary is expected to be signed with get-task-allow entitlement – could you please check if that is the case? You can verify binary's entitlements using: codesign -dvvv --entitlements=- . Kacper

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package. The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs. I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy. I tried different macOS versions in VMs (14, 15). Same result. What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.

The weird thing is, SecKeyCreateRandomKey() does create an entry with the correct ACL where only my program can access the key. In all cases I'm creating the ACL simply like so: SecAccessCreate(label as CFString, nil, &acl) The program should also have a valid code signature, because otherwise macOS doesn't even let it start up. Running from a terminal immediately results in Killed: 9, with the Console program showing an accompanying ASP: Security policy would not allow process, and opening from Finder results in The application “something.app” can’t be opened. And indeed, I do have a Personal Team set in Xcode, it's just not enrolled in the paid developer program. I did also notice that my signed executables actually ran even without updates within a year, so I simply figured that it works because my Personal Team's certificate was still in fact signed by Apple, it just doesn't have access to any restricted entitlements. Since I'm not using those, there's also no provisioning profile to deal with and thu

I built Dext with a development ID and successfully re-signed and notarized it. This time, I only notarized the Driverkit, and plan to do the installer app later. Here are the steps I tried: Signed the build using Apple Development in Xcode Re-signed the build product Zipped the build product Notarized using xcrun notarytool submit, which returned Accept. Below is a sample re-signing command. codesign --sign $CODE_SIGN_IDENTITY --entitlements --options runtime --verbose --force build/Release/.app I'll probably need to eventually create an installer app and notarize it, but I think I've temporarily resolved the recent issue of not being able to sign with a Developer ID in Xcode. If you have any issues from an engineering perspective, please let me know.

Signing a distribution USB or PCI DEXT The issues described above mean that the standard Xcode GUI flow cannot be used to directly export a distribution release of a USB or PCI DEXT. Here is that flow I've found that will work: Note: The instructions below reference macOS-specific documentation, but the flow I'm describing was actually tested using an iOS project. Start by building the final version of your DEXT. On the portal, generate and download a provisioning profile for whatever environment you're going to try to build. Generate a profile for both the DEXT and the app it will be embedded in. Rename the DEXT profile you downloaded in #2 to embedded.provisionprofile”. Show the packaged contents of your DEXT and replace the existing embedded.provisionprofile (development profile) profile with the file from #3 (the release profile). Use this command to resign the DEXT with the final entitlement configuration you'll be shipping. See the Sign each code item section of Creating distribution-signed code for mac

[quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] our earlier “Network Extension” tag was a mistake. [/quote] And presumably so was the reply you posted about 10 hours before this one |-: Anyway, the behaviour you’ve described doesn’t gel with Network Extension at all, so I’ve re-tagged your thread accordingly. When dealing with keychain sharing, there are two factors in play: Build time Run time I’m gonna focus on the build-time stuff, because a) that’s where you seem to be stuck, and b) I’m not familiar with Matter extensions and there could be run-time restrictions I’m not familiar with. So, regarding your build, you wrote: [quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] Could you enable Keychain Sharing for these iOS App IDs … ? [/quote] There’s nothing for us to enable here. Every App ID supports keychain sharing [1]. To illustrate this: I using Xcode 26.1 to create a new test project from the iOS > App templ

Any suggestions would be great. Most of the Apple documentation on USB ports is like 20 years old, and the new stuff pushes you towards DriverKit. Making this explicit, trying to do this with DriverKit is a great way to make a lot of extra work for yourself without any real benefit. You MIGHT need a codeless DEXT, but that's very different than actually using DriverKit. The USB Host framework is exactly what you want to use. I have been able to open an inservice to the device at the top level, but I get an error when I use it. What's the device? The typical issue here is that one of the class drivers has claimed the device, which blocks your access. Assuming that's the case... I started using DeviceKit, but I received signing errors. I shouldn't have to go down that path just to dump data from a USB port? ...then a codeless DEXT will let you push our driver out of the way. The article Overriding the default USB video class extension has an overview of what's involved. On the codesigning side: I start

[quote='808475021, StanLey-Pliszko, /thread/808475, /profile/StanLey-Pliszko'] Why does local codesign --verify pass but Apple notarization service fails? [/quote] I’ve seen this happen for a couple of reasons: Case sensitivity Packaging To test the first: Create a case sensitive APFS disk image. Use the Finder to copy your app to it. Run your codesign --verify test against that copy. On the packaging front, it’s common for apps using third-party tooling to not follow the guidelines in Placing content in a bundle. When that happens, the app can end up with a code signature that relies on extended attributes. And when that happens you can run into problems during notarisation because of the various ways that those extended attributes are packaged. To test this: Build your app to a disk image. Use xattr to check entire app bundle for extended attributes starting with the com.apple.cs. prefix. Finally, I want to address two other things that are unlikely to be the cause of this issue but you sh