I'm working on developing a transparent proxy provider extension, and I am trying to figure out how to handle a change in configuration that would result in a different verdict from handleNewFlow() Consider the following scenario: The proxy provider is started with configuration A, and a bunch of packet flows get a verdict of NO from handleNewFlow(). These flows are now handled by the system and get routed out to the internet normally. Some application changes the protocolConfiguration property to configuration B, and the proxy provider detects this change via KVO. This new configuration changes the verdict that would have been returned from handleNewFlow() to YES, requiring that traffic to be handled by the transparent proxy provider instead of the system. These flows should be closed (eg: by calling closeReadWithError()) but the proxy provider has no record of them because we previously returned NO Is there a way that a transparent proxy provider can get the operating system to close the currently open flows so that they can be re-evaluated by handleNewFlow() and directed into the transparent proxy instead?

Hi, We have a macOS application that contains a helper daemon that was registered with launchd using the SMAppService API and for the most part its been working okay until we tried to release an update that added an XPC service to the daemon. When users try to upgrade the software, the new service now fails to launch due to a launch constraint violation. The Console log shows the following error after the upgrade: AMFI: Launch Constraint Violation (enforcing), error info: c[5]p[1]m[1]e[0], (Constraint not matched) launching proc[vc: 6 pid: 1422]: /Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon, launch type 0, failure proc [vc: 6 pid: 1422]: /Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon The service plist before the upgrade looked like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AssociatedBundleIdentifiers</key> <string>org.mozilla.macos.FirefoxVPN</string> <key>Label</key> <string>org.mozilla.macos.FirefoxVPN.service</string> <key>BundleProgram</key> <string>Contents/MacOS/Mozilla VPN</string> <key>ProgramArguments</key> <array> <string>Mozilla VPN</string> <string>macosdaemon</string> </array> <key>UserName</key> <string>root</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>SoftResourceLimits</key> <dict> <key>NumberOfFiles</key> <integer>1024</integer> </dict> <key>StandardErrorPath</key> <string>/var/log/mozillavpn/stderr.log</string> </dict> </plist> The updated plist changes the BundleProgram, removes ProgramArguments and adds MachServices, which results in the following plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AssociatedBundleIdentifiers</key> <string>org.mozilla.macos.FirefoxVPN</string> <key>Label</key> <string>org.mozilla.macos.FirefoxVPN.service</string> <key>BundleProgram</key> <string>Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon</string> <key>MachServices</key> <dict> <key>org.mozilla.macos.FirefoxVPN.service</key> <true/> </dict> <key>UserName</key> <string>root</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>SoftResourceLimits</key> <dict> <key>NumberOfFiles</key> <integer>1024</integer> </dict> <key>StandardErrorPath</key> <string>/var/log/mozillavpn/stderr.log</string> </dict> </plist> On a fresh machine/VM, this works just fine, we only encounter the Launch Constraint Violation when upgrading from one version to the next. We were hoping that the service could have been upgraded by calling unregisterWithCompletionHandler first, but this seems have no effect on the bug. So, I guess my questions are: Is there a way to diagnose what the launch constraints are for a service, and which why the constraints are being violated? How does one go about changing the plist for a daemon installed via SMAppService? Thanks, Naomi