Posts

Post not yet marked as solved
1 Replies
2.3k Views
Hi, We are dealing in our product with an issue due to a mismatch about how the DNS TTL is handled in the backend compared with how the DNS TTL is handled in Mac device: The issue is due to different TTL values of the DNS entry saved on the Mac device and backend. For the failure case (access to some web pages is not working on Safari), the Mac device holds a DNS entry for more than 5 minutes, but the backend keeps the entry for around one minute. It results in some missbehavior in the backend for the particular FQDN once the DNS entry on the backend expires. Backend holds a DNS entry as per the TTL value specified in the A record. The Mac device appears to have a different logic, i.e., it considers the TTL value of the CNAME record instead of the A record. Is it possible to confirm how the TTL is handled on macOS? is macOS caching the Cname TTL if the resource is accessed via a name and caches A record TTL if an A record is accessed? Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
1 Replies
545 Views
Hi. We are invoking CFNetworkExecuteProxyAutoConfigurationURL (https://developer.apple.com/documentation/cfnetwork/1426392-cfnetworkexecuteproxyautoconfigu?language=objc) to download and apply automatic proxy configuration. It is working OK for most of cases but an error -1017 is retrieved when the pac file response contains the header Transfer-Encoding -Transfer-Encoding: chunked- instead of Content-Length (If Content-Length there is no any problem) Do you know if there is some parameter to configure to allow to support Transfer-Encoding in CFNetworkExecuteProxyAutoConfigurationURL? I didn't find any documentation explaining how to do this or if this a limitation on the API. Regards
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
3 Replies
742 Views
Hi. I'm dealing with an issue trying to retrieve SmartCard certificates from the app. I'm getting status -25300 (errSecItemNotFound) for SecItemCopyMatching when the smartcard is connected. The FW Security and SecurityInterfaces are add to the project. This is the code OSStatus nStatus; static const void* kKeys[] = { kSecClass, kSecMatchLimit, kSecReturnRef, kSecAttrCanSign }; static const void* kValues[] = { kSecClassIdentity, kSecMatchLimitAll, kCFBooleanTrue, kCFBooleanTrue }; osxObject<CFDictionaryRef> query(CFDictionaryCreate( kCFAllocatorDefault, kKeys, kValues, 4, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks)); CFArrayRef result; OSStatus status = SecItemCopyMatching(query.get(),(CFTypeRef *)&result); //status retrieved is -25300 Why the status my be -25300 even when the smart card if configured and connected? Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
1 Replies
472 Views
Hi, I'm having a couple of issues trying to proxy UDP flows using App Proxy Provider (Specifically I'm using NETransparentProxyProvider) I'm using iperf3 to test the UDP flows: -This command is executed in the client: iperf3 -c 192.168.100.9 -p 5011 -u -This command is executed in the backend: iperf3 -s -p 5011 I observe two problems: -Once the first set of bytes are received from the backend and are written to the flow, then there are not outgoing bytes read from the flow to be sent to the backend. -But the most significant issue is that all the subsequent flows are not received in the AppProxyProvider. The provider went to a bad state and the only option is to kill the process to start it again. In my code the AppProxyProvider is implemented with Objective C and there is a server that is the actual component that connects to the backend. (client->server->backend) But in order to figure out what is wrong I implemented a simple App Proxy Provider for UDP flows in swift using NWConnection API. So in this case there is no any server (client->backend) When the App Proxy is executed (with the proper setting to match the UDP flows with 192.168.100.9) the UDP flow is properly open in the client and backend. Then the datagrams are read from the flow and sent to the backend. Then some bytes are received from the backend and written to the client. This is the point where the issue happens: -The completion handler for writeDatagrams is success but as I mentioned before the next datagrams are not sent by the flow and most important, the Proxy Provider stops receiving new flows. These message are shown in the console app: debug 15:22:49.589076-0300 nnn.systemextension opening flow UDP [{length = 0, bytes = 0x}] local port 0 interface en0 with local 192.168.100.13:53606 debug 15:22:49.589767-0300 nnn.systemextension (2011000062): Open, sending successful connect result debug 15:22:49.589924-0300 nnn.systemextension (2011000062): Got a connect result with window size 786896 debug 15:22:49.590019-0300 nnn.systemextension (2011000062): invoking open completed event handler debug 15:22:49.590279-0300 nnn.systemextension nw_socket_handle_socket_event [C1:1] Event mask: 0x800 default 15:22:49.590326-0300 nnn.systemextension nw_socket_handle_socket_event [C1:1] Socket received CONNECTED event default 15:22:49.590426-0300 nnn.systemextension nw_flow_connected [C1 IPv4#187b93af:5011 ready socket-flow (satisfied (Path is satisfied), viable, interface: en0, ipv4, ipv6, dns)] Output protocol connected debug 15:22:49.590493-0300 nnn.systemextension nw_endpoint_flow_connected_path_change [C1 IPv4#187b93af:5011 ready socket-flow (satisfied (Path is satisfied), viable, interface: en0, ipv4, ipv6, dns)] debug 15:22:49.601342-0300 nnn.systemextension (2011000062): received 4 udp bytes from app debug 15:22:49.601432-0300 nnn.systemextension (2011000062): plugin read 4 bytes debug 15:22:49.601682-0300 nnn.systemextension providertestpablo readDatagrams success UDP flow, copier: 0 data.count: 1 dataItem.length bytes: 4 debug 15:22:49.612696-0300 nnn.systemextension providertestpablo writeDatagrams to execute UDP flow, copier: 0 length bytes: 4 copier.remoteEndpoint: 192.168.100.9:5011 debug 15:22:49.612873-0300 nnn.systemextension (2011000062): Wrote 4 bytes to the kernel (total bytes written = 4) debug 15:22:49.612931-0300 nnn.systemextension (2011000062): plugin wrote 4 bytes debug 15:22:49.613032-0300 nnn.systemextension providertestpablo write success to execute UDP flow, copier: 0 length bytes: 4 copier.remoteEndpoint: 192.168.100.9:5011 error 15:22:49.634139-0300 nnn.systemextension (0): Failed to read an entire packet error 15:22:49.634195-0300 nnn.systemextension (0): control: aborting director due to EOF default 15:22:49.634228-0300 nnn.systemextension (0): Aborting the director default 15:22:49.634275-0300 nnn.systemextension (2011000062): Closing reads (suppressing SHUT_WR), closed by plugin default 15:22:49.634314-0300 nnn.systemextension (2011000062): Closing writes, sending SHUT_RD Has anyone observed this issue before? From the API point of view there we can only invoke readDatagrams and writeDatagrams, so It doesn't look that something is wrong in the implementation.
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
1 Replies
518 Views
Hi. I'm working on a AppProxyProvider that captures TCP and UDP flows. The invocation of the method to open the flow and read bytes from it are working as expected. But I'm getting this error invoking writeDatagram: sentByEndpoints: _NEAppProxyFlowErrorInvalidArgument An invalid argument was passed to one of the NEAppProxyFlow methods _ This is shown in the console: error 14:56:27.628074-0300 XXXXX -[NEAppProxyUDPFlow writeDatagrams:sentByEndpoints:completionHandler:]: Remote endpoints array contains a non-NWEndpoint object In the code I'm creating an array with an instance of NWHostEndpoint NWHostEndpoint * endPoint = [NWHostEndpoint endpointWithHostname:[NSString stringWithFormat: @"%s", hostname] port:[NSString stringWithFormat: @"%d", srcPort]]; NSArray * endpoints = @[endPoint]; Was this issue observed by someone else?
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
2 Replies
1.5k Views
Hi. In Monterey beta 5 (the same was observed in previous betas) our application is not launched from Safari browser. The Bundle URL is properly registered in Info.plist (this is working OK in previous OS versions and also it is working ok in Monterey using other browser) The custom URL is registered in this way <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleTypeRole</key> <string>Editor</string> <key>CFBundleURLName</key> <string>NNNN</string> <key>CFBundleURLSchemes</key> <array> <string>NNNN</string> </array> </dict> </array> NNNN represents out custom url scheme I didn't find any reference about some change on this API on Monterey (https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
1 Replies
977 Views
All customers that are using some versions of our product are complaining because they are not able to connect to the service. This happens because a certificate validation done in the code is failing. The certificate didn't expire but looking into the console logs these error is observed: default 08:39:03.218259 -0300 trustd cert[1]: BlackListedLeaf =(leaf)[force]> 0 default 08:39:03.218790 -0300 trustd cert[1]: BlackListedLeaf =(leaf)[force]> 0 default 08:39:03.218897 -0300 trustd cert[2]: AnchorTrusted =(leaf)[force]> 0 default 08:39:03.219086 -0300 trustd cert[1]: BlackListedLeaf =(path)[force]> 0 default 08:39:03.221455 -0300 dsAccessService Trust evaluate failure: [ca1 BlackListedLeaf] default 08:39:03.221929 -0300 NNNService SecStaticCode: verification failed (trust result 6, error -2147409652) default 08:39:03.221964 -0300 NNNService MacOS error: -2147409652 default 08:39:03.226483 -0300 NNNService MacOS error: -2147409652 default 08:39:03.853294 -0300 trustd cert[1]: BlackListedLeaf =(leaf)[force]> 0 default 08:39:03.853663 -0300 trustd cert[1]: BlackListedLeaf =(leaf)[force]> 0 default 08:39:03.853791 -0300 trustd cert[2]: AnchorTrusted =(leaf)[force]> 0 default 08:39:03.854047 -0300 trustd cert[1]: BlackListedLeaf =(path)[force]> 0 default 08:39:03.855542 -0300 NNNService Trust evaluate failure: [ca1 BlackListedLeaf] default 08:39:03.856172 -0300 NNNService SecStaticCode: verification failed (trust result 6, error -2147409652) As you can see this is the certificate validation that fails: Trust evaluate failure: [ca1 BlackListedLeaf] We need to understand why the app certificate is blacklisted. Is there any new policy enforced by Apple to blacklist certificates?
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
3 Replies
677 Views
Hi. I implementing an AppProxyProvider that has to handle all TCP flows. This is the rule (based on https://developer.apple.com/forums/thread/667431):             NENetworkRule * filterRule = [[NENetworkRule new] initWithRemoteNetwork: nil remotePrefix: 0 localNetwork: nil localPrefix: 0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionOutbound]; proxySettings.includedNetworkRules = @[filterRule]; This is shown in the console log: [Extension *****]: provider set tunnel configuration to tunnelRemoteAddress = <14-char-str> includedNetworkRules = ( { matchRemotePrefix = 0 matchProtocol = <3-char-str> matchDirection = <8-char-str> appliesToLoopback = NO }, ) isFullyTransparent = YES This is working OK. But when I add an exclude rule (in order to sort out the issue mentioned in https://developer.apple.com/forums/thread/660195) the behaviour of the AppProxyProvider is strange: there is no any incoming flow. This is the rule:             NWHostEndpoint * tunnelHostIpRuleEndpoint = [NWHostEndpoint endpointWithHostname: @"xx.xx.xx.xx" port:@"0"];             NENetworkRule * tunnelHostIpRule = [[NENetworkRule new] initWithDestinationNetwork:tunnelHostIpRuleEndpoint prefix:0 protocol:NENetworkRuleProtocolTCP]; proxySettings.excludedNetworkRules = @[tunnelHostIpRule]; And this is shown in the console log: [Extension ******]: provider set tunnel configuration to tunnelRemoteAddress = <14-char-str> includedNetworkRules = ( { matchRemotePrefix = 0 matchProtocol = <3-char-str> matchDirection = <8-char-str> appliesToLoopback = NO }, ) excludedNetworkRules = ( { matchRemoteEndpoint = xx.xx.xx.xx:0 matchRemotePrefix = 0 matchProtocol = <3-char-str> matchDirection = <8-char-str> appliesToLoopback = NO }, ) isFullyTransparent = YES My expectation is that all flows be handled by the AppProxyProvider except the flows that match with the IP set in the exclude rule for any port. Can you please advice if this is a bug or expected behaviour and recommend some option to accomplish my goal? Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
26 Replies
4.8k Views
Trace error - https://developer.apple.com/forums/content/attachment/c14f0290-4c9b-497c-ad2e-9c95fbc495a3 Hi. In the latest days I'm unable to notarize some components (dmgs, apps, etc) because the upload of those components is failing with the error: Unable to find requested file(s): metadata.xml (1057) Sometimes it is necessary to try 2-4 times to be able to upload the components. I'm using Xcode 11.3.1 and Xcode 12.2. The notarisation was working ok with no issues previously. Have someone face a similar issue? Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
0 Replies
643 Views
Hi. I need to retrieve the current user to check if a particular application that installed in the user context (it is installed in /Users/username/Library/Application Support/..) should be upgraded when the installer (a dmg) runs. I was checking with the objects available in the Installer JS (https://developer.apple.com/documentation/installer_js) but I didn't find any way to retrieve the current user (ideally I need to retrieve the user home path) Thanks
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
1 Replies
565 Views
Hi. In the latest days the notarization of some components (dmg, apps, etc) is failing randomly because the upload is failing. The error reported is: error 01-Apr-2021 11:43:16 [2021-04-01 11:43:15 PDT] main DBG-X: parameter iTMSTransporterMode = upload I'm 99.9% sure this is an issue in the Apple notarization service because if the same component is uploaded again the notarization is success( Sometimes it is necessary to try 3-4 times to actually upload the file) This issue is happening in the latest week. Can you please confirm if something is not working properly in the notarisation service? Attached Trace log - https://developer.apple.com/forums/content/attachment/612f94d3-f1c5-49fc-a4cd-6bde78b8101d is a trace log with the error
Posted
by pa_szyrko.
Last updated
.
Post not yet marked as solved
4 Replies
776 Views
Hi. We have implemented an application with a System extension (With network filters). The application is working properly in BigSur when it is installed: The system extension activation prompt is shown and it is properly loaded once the user approve its usage. But there is a problem upgrading the application from Mojave to BigSur: the system activation prompt is not shown and this error appears in the console (filtering by 'sysextd'): default 07:44:28.170909-0300 sysextd staging extension with identifier net.**.systemextension default 07:44:28.453180-0300 sysextd Making activation decision for extension with teamID teamID("*"), identifier net.**.systemextension default 07:44:28.453363-0300 sysextd No extension policy -- activation decision is UserOption default 07:44:28.453438-0300 sysextd validating extension with identifier net..systemextension default 07:44:28.866906-0300 sysextd MacOS error: 3 default 07:44:29.015223-0300 sysextd Error checking with notarization daemon: 3 error 07:44:29.016455-0300 sysextd bundle code signature is not valid - does not satisfy requirement: -67050 code failed to satisfy specified code requirement(s) default 07:44:29.017158-0300 sysextd extension failed to validate! uninstalling... default 07:44:29.017237-0300 sysextd uninstalling invalid extension net.**.systemextension These errors are shown when the application is not notarized. But this is not the case: the application is notarized and the dmg was successfully stapled. After getting these error if the application is installed again in BigSur the system extension activation prompt is shown. Is this an expected behavior for applications upgraded from Mojave? Is this a known issue? I tried this with macOS Big Sur 11 beta 5 (20A5354i). But the same error happens with previous beta versions.
Posted
by pa_szyrko.
Last updated
.