Hi devfunshark, did you manage to fix this problem? I see the same thing when enabling Sandbox for System Extension target. SecCodeCopyGuestWithAttributes with kSecGuestAttributeAudit flag is failing with error code 100001 and I can see errors like MacOS error: -25337 and 67061 in console. If I try the same thing on App target which is also Sanboxed, it works. It's only the System Extension that's failing. I was thinking about creating a daemon which would run in the background and it would serve as a service for code signing verfication. System Extension would send audit token through XPC and daemon would do the app signature check and respond with result. Although it's probably another 0.1ms delay (well, maybe less) when comparing to doing that in System Extension with Sandbox disabled. Please let me know, if you found a better solution. Thanks, Robert

I see similar issue. When building binary, xcodebuild fails with signature error. I had to remove com.apple.token completely, although Apple's docs say it's allowed by default. Perhaps you need to use OurTeamId.com.apple.token.

Hi, I think I may have a solution for you. I was struggling with this for last several months (btw also using SecCodeCopySigningInformation), always getting back to investigate and never found a solution until now. It definitely isn't just a log noise, but a real signing problem, which could potentially block release though app store. First, some advice, which will save your time: You might find suggestions like using com.apple.developer.networking.multicast entitlement - doesn't work, you are able to build and sign system extension, but it crashes with signature error when OS tries to load it. Enabling Sandbox doesn't help either- but I definitely recommend enabling Sandbox for system extensions, you will need it for future release on App Store, if you plan it, and if you need to store/cache data, you can do it in protected group container with Sandbox on. It's worth the effort to Sandbox system extensions, although when pulishing notarized apps outside of App Store, it works without Sandbox. One of the 2 messages generated complains about applicaiton.group. Ignore that. If you need to communicate through XPC, you need app group anyway. You might find a suggestion to add keychain.access.group entitlement com.apple.token - forget it, it doesn't work with system extensions, you get a signing error when building. Although Apple's doc says com.apple.token is allowed by default, it is very likely tied to another entitlement, perhaps related to biometric reading. But keychain access group is actualy the culprit. SOLUTION: Define at least one keychain.access.group entitlement with your group ID in it, example: ABCDEFG.com.company.firewall keykeychain-access-groups/key array string$(TeamIdentifierPrefix)com.company.firewall/string /array If you do that, "invalid application signature or incorrect provisioning profile" log message will go away. Explanation: When creating bundle id, you cannot select/deselect keychain access group (there used to be a checkbox for this couple of years ago, if I remember). Provisioning profiles are now automaticlaly generated with keychain.access.group added, so you have to define it even though you don't need it. Regards, Robert

Well, it doesn't quite work with Distribution certificate, although I'm using exact same bundle id settings. The only difference between distribution and development entitlements is that System Extenion development prov.profile somehow contains following entitlement keycom.apple.developer.system-extension.install/key true/ which should only be present in the app bundle that registers extension, it should not be defined for system extension itself. In any case, it looks like this precise definition inlcuding keychain.access.group makes the error message "invalid application signature or incorrect provisioning profile" disappear: keyEntitlements/key dict keycom.apple.developer.system-extension.install/key true/ keycom.apple.developer.networking.networkextension/key array stringapp-proxy-provider/string stringcontent-filter-provider/string stringpacket-tunnel-provider/string stringdns-proxy/string stringdns-settings/string /array keycom.apple.application-identifier/key stringABCDEFGH.com.company.firewall.dev/string keykeychain-access-groups/key array stringABCDEFGH.*/string /array keycom.apple.developer.team-identifier/key stringABCDEFGH/string /dict with actual keychain value defined in the extesnion project settings as ABCDEFGH.com.company.firewall

Boot sequence with user applications starting before Launch daemons and even system extensions clearly represents a potential security risk. It is very clearly visible when using FileVault. In this case user needs to enter password, OS decrypts volume and then it can startup and launch processes, but very quickly opens user's Desktop and starts to open applications. The bigest problem is that for example Endpoint system extension, which defends computer from infections or Network system extension, which scans network traffic and defends against infected web pages, email, etc. cannot immediately block harmful content. PIDs of these processes are larger than for example Launch Daemons. It means that for example Mail could open very quickly and load new message before Network System extension is loaded and traffic captured and scanned. We see it especaily on new OS versions running on ARM where it can take up to 10-30 seconds to properly load everything to protect users. That happens when OS is setup with FileVault and user has many, many applications opened - Mail, Calendar, Safari with lots of tabs, Teams, Remote Desktop, etc, etc. When user reboots computer, we clearly see this delay in start up of critical processes that should protect users, especially in corporate environment. Bootup sequence should look something like this: System Extenisons Launch Daemons Launch Agents User applications Is there a way to setup this sequence of process start up? Thanks, Robert

That's right. Ideally we would mute the event. But simply checking a flag to determine that the file is sandboxed and handling it by es_respond_auth_result(client, message, ES_AUTH_RESULT_ALLOW, cache) would be sufficient. If it is a file our process running under root cannot access for scanning, then there is no reason to try opening it. When Installd unpacks app bundle into its sandbox, eventually it will move it into /Applications and it can be scanned there. The reason why we try to avoid opening files we cannot open is the fact that even the failure takes time. Even decision whther to use open() or access() has impact on how long the failure lasts. If the failure to open file takes 20ms, then for example an app with 50000 files could take 1000s or 16.6 minutes. Currently I'm strugling with determining whether to use access() or open() to check if the file can be accessed. There are cases where access() check is faster and cases where open() is faster (even if the result is failure) - it depends on various factors, like process has access to file, or doesn't have basic unix permissions or file is sandboxed. That's why I'm looking for ways to avoid unnecessary file system calls.

BTW does NSProvider.startSystemExtensionMode() need to be started from the main thread? Can it be started from a background thread that doesn't event use CFRunLoop, but a unix loop based on epoll? Does NSXPCListener has to be started from main thread?

Additional Info: The issue occurs only on ARM (Ventura and Monterey) not on Intel. XPC simply doesn't work after upgrading system extension on ARM. I tried to kill sysextd, nesessionmanager and other processes. Basically I'm trying to kill a process that manages XPC connections and info about processes and their signature validation (maybe it's somewhere deep in kernel and it's not possible to resolve it by this hack). It is possible that when trying to connect to XPC while starting our services in posinstall scirpt, installd hasn't quite yet completed and perhaps OS considers bundle signature not valid yet. Workaround is rebooting the machine, but we try to avoid that as much as possible. After reboot XPC works fine with upgraded system extension.

The same problem here. It only happens on ARM, haven't seen it on Intel. When replacing Network System Extension during installation in postinstall script we are hitting this issue at least 50% of the time. Isn't is possible that OS cannot correctly validate signatures of the extension or client app and that makes XPC listener kick off the client? We tried to do the following Disable network filter (not removing, just changing its state to avoid OS dialog that prompts user to allow network filter) calling launchctl stop NetworkExtension.com.company.feature.version... This stops the extenison while making registration and upgrade, we were hoping that later when enabling the network filter and extension would start with proper XPC listener that would accept connection from the client. It didn't help. Our Network Extension is not sandboxed yet. Could this help? But it works after reboot, so its only an issue right after upgrading extension.

I tried killing sysextd, nesessionmanager and other processes to reset XPC. Killing launchd was my other considerartion, but that's rather severe hack to overcome some bug in XPC initialization.

Perhaps this could help to fix XPC invalidation- add following to postinstall script: disable network filter stop network extension spctl -a -vv "${APP_PATH}" spctl -a -vv "/Applications/${PRODUCT_NAME}.app/Contents/Helpers/${MANAGER}.app" spctl -a -vv "/Applications/${PRODUCT_NAME}.app/Contents/Helpers/${MANAGER}.app/Contents/Library/SystemExtensions/com.company.feature.dev.systemextension" upgrade system extension enable network filter connect XPC client But it is possible that simply using sleep 30 before upgrading system extension would accomplish the same :-)

It would appear that the problem is solved if I add only following steps into preinstall script disable network filter stop network system extension After that installd replaces the bundle and system extensions in it, postinstall then runs our helper, which registers system extenison and starts the network filter (starts TransparentProxy/AppProxy). I guess stopping system extensions while the old bundle still exists, then replacing the bundle and upgrading system extension (basically it just registers new verison of the extension as the process is not running anymore) causes OS (launchd) to clear up XPC related caches.

I need to replace Subtitle and Audio icons by one icon which will combine Audio and Subtitles, then add a few other icons, for opening a list of channels so user could switch channel, opening EPG and other icons with specific actions. WWDC 2022 video didn't help me either https://developer.apple.com/videos/play/wwdc2022/10147/ BTW: Why I can only set metadata to display a few specific things, like title and subtitle and I cannot add any view I want, change position od "LIve" badge, etc. AVPlayerViewController.contentViewController property is readonly. I have to traverse view hierarchy and hierarchy of view controllers of AVPlayerViewController and hack those existing views, which is tricky, may not be reliable for future tvOS releases, may require more maintenance and use of #ifdef or #if available() or whatever. Isn't there a better approach? Here is an example:

Feedback number is FB13191404. I see that there might be someone else reporting this.

I'm seeing this on tvOS 17 real hardware when trying to load images using AVAssetImageGenerator.generateCGImageAsynchronously and I'm not getting any images from the asset. But it works on tvOS simulator.