Supported diagnostics for CSSMERR_TP_NOT_TRUSTED on a macOS system executable

Code Signing General
rain0210 OP
Created
Replies 3
Boosts 0
Views 529
Participants 2

I would like to identify a supported, minimally scoped diagnostic method for a code-signature verification failure, without changing certificates, trust settings, or system protections.

The command execution environment reported macOS 27.0.1, build 26A434. The following command was run against the standard system executable:

/usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf

It returned exit status 1 with:
CSSMERR_TP_NOT_TRUSTED
In architecture: arm64e.x1

The designated requirement displayed for the file was:
identifier "com.apple.printf" and anchor apple

The signature display reported Authority=(unavailable). Following TN3161, the CMS data was inspected structurally: it contained three certificate structures, whose recorded validity periods included the observation date. This was not a cryptographic or trust validation, and I do not treat the file as authenticated.

My question is how to distinguish a certificate/trust rejection from inability to complete evaluation in the command's execution context. The documentation for SecStaticCodeCheckValidityWithErrors describes detailed errors, and kSecCodeInfoTrust describes access to the trust object used in code-signature evaluation. Is either a supported diagnostic route for this system executable and architecture? If so, please identify the required flags, prerequisites and minimum non-sensitive result fields. In particular, I do not want to change the strict or architecture coverage merely to obtain a passing result.

No diagnostic using those APIs has been implemented or run. I am not asking to re-sign the system file, install certificates, reset trust settings, disable protections, or bypass validation. I would prefer an initial diagnostic that does not require private Keychain contents, broad system logs, or a full diagnostic archive.

I understand that a diagnostic result or a successful information query would not by itself authorize execution or prove that the environment is safe.

Answered by DTS Engineer in 911980022
Written by rain0210 in 911383022

the failing invocation is launched through the command-execution tool in the ChatGPT desktop app (Codex)

Given that this issue only shows up with your third-party tooling in play, that’s something you should ask the vendor about.

My experience is that third-party LLMs commonly use a custom SBPL-based sandbox, and that’s not something we support. See this thread for more about that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  3
Boosts 0
Views  529
Participants  2
DTS Engineer OP
Apple

I’m confused. This works for me from Terminal on macOS 27:

% sw_vers
ProductName:		macOS
ProductVersion:		27.0
BuildVersion:		26A428
% codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf
/usr/bin/printf: valid on disk
/usr/bin/printf: satisfies its Designated Requirement
/usr/bin/printf: explicit requirement satisfied

Are you spawning codesign from some other environment? If so, what is that?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
rain0210 OP

Thank you. Yes—the failing invocation is launched through the command-execution tool in the ChatGPT desktop app (Codex), rather than entered directly in Terminal.app.

My Mac is running macOS 27.0.1, build 26A434. The app reports version 26.1013.40934, with “Powered by Codex & OWL” branding. I have not independently identified its bundled command-runner version.

The tool reports a workspace-write sandbox with restricted network access. OpenAI documents the use of Seatbelt on macOS, but I have not captured the effective sandbox profile or established whether access to a particular security service is denied.

The exact verification command was:

/usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf

On October 23, the results were:

  • From the agent’s command tool, with a pre-verification timestamp of 08:51:00 UTC: CSSMERR_TP_NOT_TRUSTED, architecture arm64e.x1, exit status 1.
  • From ordinary Terminal.app, with a pre-verification timestamp of 08:57:15 UTC: all three verification messages indicated success, exit status 0.

The timestamps are 6 minutes 15 seconds apart, so this was not a simultaneous or cache-controlled comparison.

Separately collected OS/build information, SHA-256 hashes of both executables, UID, launchctl manageruid and managername matched between the two contexts. These checks do not establish identical sandbox or service-access conditions.

I have not changed certificate trust settings or disabled security protections.

Is there a supported, narrowly scoped diagnostic that would distinguish certificate trust-evaluation failure from inability to reach a required trust/security service in the restricted execution context? I would prefer not to collect broad private logs or modify the sandbox.

DTS Engineer OP
Apple
Recommended
Written by rain0210 in 911383022

the failing invocation is launched through the command-execution tool in the ChatGPT desktop app (Codex)

Given that this issue only shows up with your third-party tooling in play, that’s something you should ask the vendor about.

My experience is that third-party LLMs commonly use a custom SBPL-based sandbox, and that’s not something we support. See this thread for more about that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"