Thanks, Quinn. We followed your advice for Apple CLT Python3.framework. Both codesign --verify --strict --deep and an explicit requirement (identifier "com.apple.python3" and anchor apple) passed outside our restricted sandbox. gktool scan reported: "Scan completed and software is allowed by system policy." The earlier CSSMERR_TP_NOT_TRUSTED remains unexplained, not evidence of a bad signature. Your guidance was very helpful.

Yes — exactly. The check would run locally on the specific Mac whose standalone Command Line Tools installation we want to validate. In particular, we want to inspect the Apple-delivered Python under /Library/Developer/CommandLineTools/... as installed on that Mac. The check can absolutely take advantage of macOS system frameworks, trust services, code-signing APIs, or other Apple-supported local machinery available on that Mac. We do not need the procedure to be portable to Linux or to work as an offline remote verifier. Our preference is for a non-destructive, auditable procedure that does not modify trust settings, bypass execution policy, or re-sign anything. If macOS already provides a supported way to determine that the installed CLT Python is valid and currently accepted under the system’s code-signing/trust policy, that is exactly the procedure we are looking for.

Yes — exactly. I’m referring specifically to the copy of Python installed by Apple’s standalone Command Line Tools package obtained from Developer > Downloads > More Downloads. In particular, I mean the unmodified Apple-delivered Python framework/executable under /Library/Developer/CommandLineTools/..., not the Python copy inside Xcode.app, not a macOS system Python, and not a Homebrew or other third-party installation. My goal is to have a supported, auditable procedure for that specific Apple-delivered executable that distinguishes: code-signature integrity and origin; whether macOS currently accepts it under the system’s trust/execution policy; and if independent revocation evidence for its signing chain is required, what Apple-supported source or procedure should be used for that evidence. I’m not trying to replace macOS trust evaluation, modify trust settings, bypass execution policy, or re-sign the binary. Thanks for narrowing the scope.

Thank you, Quinn. Our high-level goal is to establish a supported, auditable verification procedure for an unmodified Apple-supplied Command Line Tools Python executable used by local development tooling. We want to distinguish code-signature integrity and Apple origin, the result of the relevant macOS trust or execution-policy assessment, and any independently available certificate-revocation evidence. We are not trying to replace macOS trust evaluation with a standalone CRL check, bypass an operating-system decision, change trust settings, or re-sign Apple binaries. For this first-party Apple command-line executable, which supported verification procedure and retained diagnostic evidence would you recommend? What does that evidence establish, and what should we avoid inferring from it? Our narrower certificate question remains whether Apple publishes current revocation-status evidence covering this exact legacy intermediate, or documents that such evidence is not publicly available. We would keep that limitation separate from the operating system’s assessment.