Hello, Thank you a lot for the help! Yes, es_message_t.process and es_event_exec_t.target are different (the field pidversion).

Thank you a lot for your help!

FB24771873 has been created. Thank you a lot!

Thank you for the help! The resource leak issue is gone after the update. The issue is no longer reproducible.

Thank you a lot for your help!

I am afraid, due to our DLP requirements, we cannot allow applications to establish connections independently, bypassing our security controls. Therefore, unless an app explicitly matches an exclusion filter, handleNewFlow(_:) always returns true. Am I correct in understanding that an application only establishes the actual network connection after handleNewFlow(_:) returns? Furthermore, I want to clarify the exact behavior if my Network Extension returns false. Could traffic potentially bypass the DLP in that scenario? Is there any guarantee that the app will be completely blocked from connecting to the remote host if the extension does not handle the flow (i.e., returns false) in case of ETIMEDOUT issue? Thank you for your help!

Thank you very much for the help! It looks like the easiest way is to immediately fail the flow’s open request when the connection enters the nw_connection_state_waiting state. According to the documentation, closeWriteWithError: and closeReadWithError: must take either nil or an NSError with the NEAppProxyErrorDomain. Therefore, it seems that the error codes used for flow closure are restricted to NEAppProxyFlowError values. If so, does the client application receive ECONNREFUSED when NEAppProxyFlowErrorRefused is passed? Is my understanding correct?

Hello, I am working on Network Extension and I have faced with the same issue: 10:33:53.854803+0300 com.my_app.transparentproxy (0): data: write error: Message too long 10:33:53.854840+0300 com.my_app.transparentproxy (0): Aborting the director 10:33:53.854862+0300 com.my_app.transparentproxy (1452558381): Got an error when sending 131072 bytes to the kernel: Message too long Looks like the issue appears with buffer length 131072 which is equal to 2^17 in all logs above (my and other threads). In my system net.inet.tcp.recvspace is equal to 131072 # sysctl -n net.inet.tcp.recvspace 131072 I solved this issue by restriction of max buffer length (64k) (system call nw_connection_receive). I found the solution by trial and error. In case of using (net.inet.tcp.recvspace -1), I see the same issue. So, it is unclear max value of the maximum_length. Are there any recommendation? Thank you in advance, Pavel

That sounds promising. Thank you a lot for this information!

Thank you for response! I am going to use onDemandRules to startup Transparent Proxy. NEOnDemandRuleConnect *connectRule = [NEOnDemandRuleConnect new]; connectRule.interfaceTypeMatch = NEOnDemandRuleInterfaceTypeAny; Is it supported way?

Hello, Thank you a lot for the time and responses! However, further research into the certificate installation completely confused me. sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain security find-certificate -c "my cert name" -Z | grep "SHA-1 hash:" | awk '{print $3}' security trust-settings-export -d ExportedTrustSettings.plist Modify the 'ExportedTrustSettings.plist' file. Find and remove the section with the key generated in step 2. sudo security trust-settings-import -d ExportedTrustSettings.plist Check if the trust setting is reset. sudo security delete-certificate -c "my cert name" /Library/Keychains/System.keychain sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain Result: the certificate is trusted. I cannot understand whether this is a bug, a feature, or an incorrect use of the 'security' tool. Thank you in advance!

Hello, Thank you for the help. As I understand it, trust settings are stored separately from the certificate. Does this mean that I can pre-configure the necessary settings during the software installation? For example, by having a post-install script call "security trust-settings-import". The second question is about "security trust-settings-import" usage. From what I see, security trust-settings-import operates on an XML file that contains the entire list of trust settings (previously generated by trust-settings-export). Is there a supported way via the command line to import trust settings for only one specific certificate, rather than applying or merging the entire global list? For example, can the XML file be stripped down to only include the target certificate, or is there another CLI approach to apply custom trust settings to a single certificate during installation? Thank you in advance.

thank you for the help!

Hello, Thank you for response. Is there any way to reset the "Always Trust" policy? The following sequence of commands leads to installing a root CA with the "Always Trust" policy: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain //MyCertificate.cer change policy to "Always Trust" sudo security delete-certificate -c "MyCertificate.cer" //MyCertificate.cer sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain //MyCertificate.cer Result: the newly installed certificate is trusted after step 4. Thank you for the help!

thank you for the help!