We have a developer-id application which includes a LaunchAgent, couple of LaunchDaemon and a system extension. We want to store our secure data in keychain that can read by any of our processes or at least by LaunchDaemons. We would also prefer for our data to not be visible to users, not be accessible to other processes and we did not want to use system keychain because of our prior experience where one of our app data on update corrupted the system keychain for one customer. Therefore, we have decided to create our own keychain file and store our data there. However, we noticed that SecKeychainCreate and related file based keychain APIs are deprecated. This led me to below threads: https://developer.apple.com/forums/thread/685546 https://developer.apple.com/forums/thread/712875 https://developer.apple.com/forums/thread/696431 And now I am confused. It is suggested that we should use data protection based keychain because file based keychains are on path to deprecation. However, it is also noted that data protection keychains do not work with LaunchDaemons. So which keychain is the right choice for our requirements? Also, One tricky aspect of this is that the SecItem API supports both keychain implementations I do not see any option to use file based keychain using SecItem API. How can I create a new keychain file at a given path and add data in it using SecItem APIs? Can someone please elaborate on this with example?

We are developing a lightweight VPN client inside a daemon process that will run even when no user session is active on machine. The lightweight VPN runs in machine context and does not require user session. We would like to display some basic diagnosis information about our lightweight client on macOS login window before user is logged into their machine (in case users need that). So, is it possible to display a UI window on login screen with some basic info that user can interact with. If yes, where can I get started? Please note, this is not an authorization plugin. We are just wanting to display info about our process that runs a lightweight VPN client on macOS login screen.

In our macOS daemon process, we are trying to validate a leaf certificate by anchoring intermediate CA cert and evaluating it using SecTrustEvaluateWithError. The leaf certificate contains couple of non-critical MS extensions (1.3.6.1.4.1.311.21.10 and 1.3.6.1.4.1.311.21.7). The macOS API fails to parse these extensions and does not evaluate the cert chain. Below is the error returned: { NSLocalizedDescription = "\U201abc\U201d certificate is not standards compliant"; NSUnderlyingError = "Error Domain=NSOSStatusErrorDomain Code=-67618 \"Certificate 0 \U201abc\U201d has errors: Unable to parse known extension;\" UserInfo={NSLocalizedDescription=Certificate 0 \U201abc\U201d has errors: Unable to parse known extension;}"; } As per RFC2459, a non-critical extension can be ignored by the system: A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. So, why does macOS not ignore these non-critical extension and returns a failure? OS version is 14.4.1.

I am trying to fetch static routes added on my mac machine by DHCP server. I am able to get DHCP info using SCDynamicStoreCopyDHCPInfo and then get DHCP options using DHCPInfoGetOptionData. However, I could not find any API that can help me parse the raw data returned by DHCPInfoGetOptionData. Since macOS is parsing and adding these static routes and also displaying them in AdditionalRoutes of service, is there any API available to developers to parse this raw data into destination, mask and gateway?

Is it possible to disallow users from disabling System Integrity Protection on their Mac machines? We have organisation Mac machines allocated to employees and we would like to keep those machine safe by not allowing users to disable SIP and remove MDM profile or perform any unsafe action. Is it possible? We would be interested even if there is any non-MDM solution can prevent users from disabling SIP.