Thank you very much for the clear-cut explanation!

Thank you very much. One more thing to clarify! I would like to confirm one specific point regarding the ordering guarantees of Endpoint Security notifications. Does Endpoint Security guarantee that the order in which NOTIFY events are delivered to a single es_client_t matches the actual chronological order in which the corresponding file operations occurred in the kernel? For example, if a process performs open() followed by close() on the same file descriptor, is it guaranteed that ES_EVENT_TYPE_NOTIFY_OPEN will be delivered before ES_EVENT_TYPE_NOTIFY_CLOSE, assuming both events are generated, neither is dropped, and the client is subscribed to both event types? The es_new_client documentation guarantees delivery in the order the system delivers messages, while the WWDC20 session "Build an Endpoint Security app" states that ES delivers messages in the same order as the events occurred on the system (video 32:50). I would appreciate confirmation of whether this guarantee applies to the actual chronological order of file operations in the kernel, rather than just the order in which messages are queued or delivered to the client.

Well, unfortunately, as I understand it, there is currently no reliable way to track file size immediately before and after each write operation on macOS using public APIs. Thank you very much for the detailed clarification!

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.