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

[kycrow32]

Description

The command
sudo security authorizationdb write com.apple.trust-settings.admin allow
fails with response
NO (-60005)

Our organization uses certificates installed on the system to authenticate to a wide variety of platforms and, per best practices, we rotate our certificates regularly (roughly monthly). Our org provides scripts to perform these updates because there are over 100 certs that get updated.
Since MacOS15, running these scripts requires a user to manually enter their password for every certificate installation. The only feasible way to do this is to place a password in the clipboard and to paste it in the window prompt. This is insecure and error prone.

Please revert this change, OR, provide the same functionality through a different mechansim.

This is the same issue reported in #11893

Platforms affected

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

Runner images affected

• 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

The command
sudo security authorizationdb write com.apple.trust-settings.admin allow
fails with response
NO (-60005)

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. run 'sudo security authorizationdb write com.apple.trust-settings.admin allow'
2. see failure 'NO (-60005)'

[archita105]

Hi @kycrow32,
Thank you for bringing this issue to our attention. We are looking into this issue and will update you on it after we investigate.

[archita105]

Hi @kycrow32!,
We replicated the issue and getting same error.
It has been observed that the command sudo security authorizationdb write com.apple.trust-settings.admin allow is explicitly blocked at the system level, even when executed with sudo .
This is because of enhanced security measures, specifically System Integrity Protection (SIP) and Transparency, Consent, and Control (TCC) restrictions implemented within the macOS operating system.