Our updating process is a launchd daemon that will download zipped bundle directories that contain resources to be used for updating. One of the bundles is an app that has a tool that is executed to perform the updating after all of the bundles have been downloaded. We are finding that on Sonoma starting in version 14.1 the zip extraction of the bundle containing the executable now is blocked on about 1 in 7 computers when the bundle directory itself is being created. <redacted>Updater <subsystem> Error during Extract state: Error Domain=<our error domain> Code=2001 "filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]" UserInfo={NSLocalizedDescription=filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]} We have seen the following error just preceding the above on some of these failures: <date> Error 0x45c755 184 0 sandboxd: tcc_server_message_request_authorization(kTCCServiceSystemPolicyAppBundles) failed: Error Domain=kTCCErrorDomain Code=2 "missing 'auth_value' in reply message" UserInfo={NSDescription=missing 'auth_value' in reply message} <date> Error 0x0 184 0 sandboxd: [com.apple.sandbox.reporting:violation] System Policy: <redacted>Updater(1431) deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle Violation: deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle I believe that the kTCCServiceSystemPolicyAppBundles failure occurs because TCC has determined that our Updater does not have permission to modify the Installer.bundle. Both the Updater and Installer.bundle have been signed by the same Apple Developer certificate (with the same team id). The Updater has been using this same procedure successfully but starts failing after the update to Sonoma v14.1. When this failure occurs, the updater has been able to extract the other resource-only bundles (no executables) that precede it. Computers that have this failure show the updater in the System Settings > Privacy & Security > Full Disk Access list as disabled. The computers that do not see this failure, do not have the updater listed in Full Disk Access. This has been raised as Feedback #FB13359407 What is the recommended way that an updater is supposed to create a new copy of an application without running into these TCC errors? Would extracting the app bundle as a directory without the .bundle extension and then renaming the directory to add the .bundle extension be a reasonable approach? BTW: The above approach does seem to work on Sonoma v 14.1 At what point does an app become subject to kTCCServiceSystemPolicyAppBundles? Is it is just a directory with a .app or .bundle extension or when a bundle structure exists that a signing check can validate?

A connected NETransparentProxyProvider will not call handleNewFlow() for network traffic that matches the NETransparentProxyNetworkSettings when running in a Parallels VM on macOS Ventura beta 9. This works on real x86 and ARM hardware. Previous macOS betas and release versions do not have this problem with Parallels. Has anyone else seen this? Is there a workaround?

I have a transparent proxy as a subclass of NETransparentProxyProvider (Xcode 12.2beta3). After setting up the NERules to receive TCP outbound traffic, my handleNewFlow override is called as expected. In macOS 11 beta 9 handleNewFlow was getting IPv4 addresses in the flow.remoteEndpoint.host property for Safari browser connections but in macOS 11 beta 10 it gets hostnames (e.g.	www.apple.com) rather than the IP addresses. What is the best way to resolve the hostnames to IP addresses within the handleNewFlow override that would insure that the default resolver and any configured DSN proxies are used?