“codesign”

Thanks for the replies. You are both quite right that I should have provided more information. When I say that notarization succeeds, I mean that I submit the dmg file produced by the build to the Apple notarization service and receive a status of 'Accepted'. I take this to mean all is well. When I say that notarization fails, I mean that the notarization step produces a status of 'Invalid'. Retrieving the notarization log indicates that the binaries were not signed. I've just gone through this again with my two machines. The build here is performed by scripts that are maintained in source code control and forced to be identical in both setups. The build infrastructure is also the same for both. Before beginning, both machines were powered off for a period of time. Power up one machine. Ensure the source tree is up-to-date. Run the build to produce a signed dmg. Submit it for notarization. The submission produces a status of Accepted. Power down the first machine. Power up the second machine. Again ensure the

Hi all, I’m seeing the same behavior and it’s currently blocking me from shipping my product. Starting Jan 6–7, every notarization submission stays “In Progress” indefinitely (I’ve waited 8+ hours with no transition to Accepted/Invalid). This includes a minimal control submission: I created a tiny AppleScript .app, signed with Developer ID + hardened runtime, zipped with ditto, and submitted via xcrun notarytool submit. That submission also remains In Progress. I’ve verified signatures with codesign --verify --deep --strict, confirmed my Developer ID cert is valid, and checked for account/agreement issues. The only time I’ve seen a terminal state recently is when a submission fails validation quickly (Invalid), but anything that enters processing appears to stall. I currently have multiple submission IDs stuck in notarytool history. Has anyone found a workaround or received guidance from Apple Support? Happy to share submission IDs/timestamps if that helps with escalation. Thanks.

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