macos-15 fails on sudo security authorizationdb write com.apple.trust-settings.admin allow with error NO (-60005)

[JarLob]

Description

The run fails with Warning: NO (-60005)

See in the same run it works on Macos-14

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

20250120.596

Is it regression?

Regression from Macos-14

Expected behavior

Pass as it does on Macos-14

Actual behavior

Fails with

Warning: NO (-60005)

Error: Exited with code 255

Repro steps

1. Fork https://github.com/GitHubSecurityLab/actions-permissions
2. Run https://github.com/GitHubSecurityLab/actions-permissions/blob/macos-15/.github/workflows/test.yml from the macos-15 branch.

It runs this script which can be simplified:
https://github.com/GitHubSecurityLab/actions-permissions/blob/5c0f276d58deb0ba6463350caaff6b8e8c392125/monitor/setup.sh#L21-L56

[archita105]

Hi @JarLob ,
We will investigate the issue and keep you posted on further updates.
Thank you.

[archita105]

Hi @JarLob,

The error code -60005 encountered on macOS-15 runners, originating from macOS's Security framework, indicates a permission denial when attempting to access or modify protected system components, such as keychain or authorization settings. Specifically, this issue manifests with commands similar to:

sudo security authorizationdb write com.apple.trust-settings.admin allow

Reason for Discrepancy Between macOS-14 and macOS-15

GitHub-hosted macOS 15 runners enforce stricter security protocols compared to macOS-14, resulting in the following challenges:

1. System Integrity Protection (SIP):
   SIP restricts modifications to certain system-level configurations, such as authorizationdb and System.keychain, even when executed with sudo.

2. Transparency, Consent, and Control (TCC):
   TCC enforces additional permissions for modifying trust settings. Such modifications typically require GUI-based user consent, which is impractical in a CI environment.

Consequently, commands that attempt to modify authorizationdb settings or add certificates to the System.keychain either fail silently or return the error code -60005. This ultimately causes workflows to terminate with an exit code of 255.

Recommendations:

To mitigate this issue and ensure compatibility with macOS-15 runners, we recommend the following approaches:

Utilize Local Keychains: GitHub-hosted macOS runners provide support for local keychains. Adopting this method eliminates the requirement to modify the System.keychain and ensures compatibility with the security restrictions of macOS-15.

Leverage Environment Variables or Configuration Files for Trust Settings: Instead of attempting to modify system-level trust databases, consider utilizing environment variables or application-specific configuration files to manage trust settings. This approach circumvents the permission restrictions encountered on macOS-15.

[archita105]

Hi @JarLob,

Following up on my previous comment regarding the -60005 error on macOS-15 runners, have you had a chance to review the information and the suggested recommendations for utilizing local keychains or environment variables/configuration files for trust settings?

[JarLob]

Hi @archita105 I have time to look at it yet. Do you have more information about Local Keychains you are referring to?

P.S. Out of curiosity, was the #11893 (comment) ChatGPT generated?

[archita105]

Hi @JarLob ,
As an alternative and more secure method for managing code signing identities and developer certificates within your CI/CD workflows, local keychains allow you to generate, import, and export certificates within a user-specific context, without requiring modifications to the system's trusted certificate store.

If you possess valid code signing identities or developer certificates obtained from Apple Developer Certificates, you can import them into your local keychain.
You can verify the available keychains using the following command:
security list-keychains

To import your certificate into a specific local keychain, use the following command, adjusting the file path and keychain name accordingly:
security import path/to/your/certificate.cer -k ~/Library/Keychains/your_keychain.keychain -T /usr/bin/codesign

To access the certificates within your local keychain during your CI/CD workflow, you can store the local keychain file as a secret in your repository settings. Subsequently, you can unlock the keychain in your workflow using the following steps:

- name: Unlock Keychain
  run: security unlock-keychain -p "${{ secrets.KEYCHAIN_PASSWORD }}" ~/Library/Keychains/build-credentials.keychain
  env:
    KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}

You can then list the available code signing identities within the unlocked keychain using a command like:

- name: Check code signing identities
  run: |
    security find-identity -v -p codesigning ~/Library/Keychains/build-credentials.keychain

Above steps will avoid the permission issues associated with modifying the system-wide certificate store.

Or else if the environment remains in its default security state, you can also follow GitHub's built-in permissions system instead of GitHubSecurityLab/actions-permissions/monitor@macos-15.

permissions:
  contents: read
  id-token: write
  actions: read

[archita105]

Hi @JarLob !
Did you get a chance to look at the local keychain workaround I shared?

[archita105]

Hi @JarLob !
Did you get a chance to look into the workaround I shared?

[JarLob]

The goal is to intercept all users, so the workaround is not an option. Since there is nothing that can be fixed at runner-images, I'm closing the issue.