Post

Replies

Boosts

Views

Activity

Reply to Clang warning about 'xar_open' API deprecation in macOS 12.0. How to address/replace with a more approprite API?
[quote='833855022, DTS Engineer, /thread/779910?answerId=833855022#833855022'] Note that the --raw option gives you machine readable output, which is a step up from pkgutil. [/quote] The raw output in spctl sounds interesting. Thanks for pointing it out. We will look into it. Our current dilemma why we also considered relying on spctl is because xar API returns us subject names as strings. I haven't seen yet a way to distinguish between subjects specific to Apple vs. company specific certificates. So when we extract information from a Developer ID Installer certificate, it gives an array like this ["", "G2", "Apple Certification Authority"] This is the result of using xar_signature_get_x509certificate_data API and then passing the data to SecCertificateCopyValues API to extract kSecOIDX509V1SubjectName field We would like to make sure that the signature contains only authorized team IDs to prevent cases where unexpected team IDs are present in addition to the expected one. The problem that sparked this discussion was the fact that the certificate that corresponds to "", the actual Developer ID Installer certificate, is not trusted by a clean system. The certificates higher in the chain are trusted. Those with subject names "G2" and "Apple Certification Authority". So we cannot put a requirement for Developer ID Installer to be passing SecTrustEvaluateWithError check. That is why spctl command was considered as a replacement to xar. In a way, spctl covers both bits on the validation that we are interested in. It can check that Gatekeeper accepts the package and it provides the teamID information.
Topic: Privacy & Security SubTopic: General Tags:
Apr ’25
Reply to Clang warning about 'xar_open' API deprecation in macOS 12.0. How to address/replace with a more approprite API?
[quote='834103022, DTS Engineer, /thread/779910?answerId=834103022#834103022'] Honestly though, this starting to get really ugly. [/quote] Yeah. I agree. I definitely wouldn't want to complicate the approach even further. We have already managed to shoot ourselves in the foot with requiring trust for each certificate in the chain. So right now we have a situation where Gatekeeper successfully evaluates a package signature validity but our code treats it as invalid. That's why I was considering to delegate the trust verdict decision to Gatekeeper and get team ID from xar APIs to use as an extra requirement without manual evaluation of trust on our side. So with that in mind, using spctl for checking signature validity and extracting specific fields from the certificate chain seems a more proper solution. I'll look into xar options. But definitely won't continue with that if it turns out needing a private API. I would want to decrease the number of cases where we have that and not increase :) Thanks!
Topic: Privacy & Security SubTopic: General Tags:
Apr ’25
Reply to Clang warning about 'xar_open' API deprecation in macOS 12.0. How to address/replace with a more approprite API?
[quote='834103022, DTS Engineer, /thread/779910?answerId=834103022#834103022'] file an enhancement request for an API that directly supports what you need [/quote] Filed FB17188856 specifically for providing an API to validate Installer package (.pkg) signature. Linked the original one FB17148233 with a question about xar APIs for reference.
Topic: Privacy & Security SubTopic: General Tags:
Apr ’25