A restricted local metadata-only OpenSSL command startup aborted with EXC_CRASH/SIGABRT. A correlated crash report displayed termination namespace0x23, code2. We have not uniquely tied that report to a saved PID/build identity, so attribution remains qualified. The control was an OpenSSL x509 metadata command reading via standard input under a custom deny-default process sandbox denying network and Mach lookups. No signature verification of a provisioning profile ran; we do not know which operation or rule caused the abort. The control did not establish provisioning-profile authenticity.
Recorded environment: macOS26.7.1/build25G241; one read-only kern.version query returned Darwin25.6.0 and XNU12377.161.15.700.19~2. We have not assumed those identifiers establish an equivalence to a published source revision. Apple published XNU at commit f6217f891ac0bb64f3d375211650a4c1ff8ca1ea defines OS_REASON_LIBIGNITION35 in bsd/sys/reason.h, but that file does not define LIBIGNITION code2.
Could Apple clarify: 1.Is there a documented meaning of LIBIGNITION termination code2 applicable to this runtime, and a supported way to identify its originating failure without relaxing security controls or relying on undocumented namespace guesses? 2.What is the supported Apple procedure for verifying a development provisioning profile and signer policy without modifying global trust/keychain settings? We do not want to substitute an invented OpenSSL purpose/OID policy for Apple's validation.
We have made no security-setting changes or signing/build/install retry as part of this inquiry. No certificates, profiles, credentials, account/device identifiers, private paths, raw logs or source code are included. This is a request for documented guidance, not approval to weaken a sandbox. No message has been submitted.