Locally created keychain can't be unlocked on macos-14-arm

[AlvaroPalmaAsteMicrosoft]

Description

In a local arm64 machine, the following flow works with no issue:

# Create a new temporary keychain to be used by my binary
security create-keychain -p <password> <new keychain>
# Add the new keychain to the search list
security list-keychains -d user -s <new keychain> <existing keychains>
# Set the new keychain as the default one (so SecItemCopyMatching searchs on it)
security default-keychain -s <new keychain>
# Explicitly unlock the new keychain, just to be sure.
security unlock-keychain -p <password> <new keychain>
# Disable timeouts on the keychain to avoid potential issues.
security set-keychain-settings <new keychain>
...
<Call a binary invoking SecItemCopyMatching()>

However, this same flow doesn't work when using the image, resulting on the error:

The user name or passphrase you entered is not correct.

Platforms affected

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

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• Ubuntu Slim
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

20251216.0055.1

Is it regression?

N/A, as there wasn't a macos-13-arm image to compare with.

Expected behavior

The binary should be able to access the keychain and search for the item.

Actual behavior

The call to SecItemCopyMatching always results in the described error message:

The user name or passphrase you entered is not correct.

Despite the fact the keychain has just been created and unlocked.

Repro steps

1. Create and unlock a new keychain using the described steps.
2. Run a binary invoking SecItemCopyMatching

Interestingly, the issue doesn't happen on the equivalent Intel image. Maybe because Intel is run through Rosetta?

[erik-bershel]

Hey @AlvaroPalmaAsteMicrosoft!

I'll have a look. Sounds interesting.

[erik-bershel]

Hey @AlvaroPalmaAsteMicrosoft! 👋

I’ve verified the following on the macOS Arm images:

• The temporary keychain is created at an absolute path and exists on disk.
• It is successfully unlocked, set as the default keychain, and added to the user search list.
• The runner is operating in a valid user GUI session.
• The keychain is readable by an independent process (security dump-keychain succeeds).

This confirms that keychain creation, unlocking, and system-level accessibility are working as expected. 🤔

Next, the differences between the Apple Silicon-based versions of MacOS and the Intel-based version come into play. Unfortunately, they are not identical in their behavior, including security part. 😞

To continue the investigation, I need to see the system-side decision that occurs when SecItemCopyMatching() fails.
Please collect macOS system logs for about a couple of minutes (please set target time to be the same as the binary execution time + 1m) immediately following the failure.

Add the following step after the failing step in your Azure DevOps job:

- script: |
    echo "Collecting system logs..."

    log show \
      --last 2m \
      --info
  displayName: Collect macOS system logs
  condition: always()

These logs are required to understand why the system rejects the keychain access request. Once available, I can continue the analysis based on diagnostics data. I'll be waiting. 🙇

[AlvaroPalmaAsteMicrosoft]

Hi @erik-bershel.

Thanks for looking into this, I'll run your suggestion and provide you with the output in a following update.

In the meantime, regarding your analysis, I can give some updates:

The runner is operating in a valid user GUI session.

Since I'm running on a pipeline, I don't have access to the GUI session I guess, and, IIRC, remote sessions are subject to extra security measures on Mac, right?

This confirms that keychain creation, unlocking, and system-level accessibility are working as expected.

I agree on keychain creation, unlocking, in the sense that I can even do a security show-keychain-info on the temporary keychain, and that works fine. However, the next part in the process always returns the incorrect user/password error message I described (although both are contained within the same pipeline step, I thought this was an issue due to keychain creation/unlocking happening in one step, and usage of that keychain in another, so I merged both into a single script, but the problem still remains). On the other hand, I don't try to access the System keychain, so I can't answer about that.

One thing that puzzles me is this entry on the Apple Developer reference regarding SecItemCopyMatching (https://developer.apple.com/documentation/Technotes/tn3137-on-mac-keychains):

Queries, like those done using [SecItemCopyMatching(_:_:)](https://developer.apple.com/documentation/Security/SecItemCopyMatching(_:_:)), consult all keychains in the search list. Use [kSecMatchSearchList](https://developer.apple.com/documentation/Security/kSecMatchSearchList) to override this.

IMHO, it suggests that, despite a value having been found in the default keychain, SecItemCopyMatching (unless explicitly changed in the app) will still keep looking for it on other keychains for the current user (for example, the login keychain), which might explain why my app is failing (as I don't unlock the login keychain on the pipeline).

However, that contradicts my local testing, where I don't unlock the login keychain either, but this app still works fine!!! So this is where I wonder if there's some setting difference on the image compared to my local environment.

[erik-bershel]

That's basically what I'm getting at. The problem is unlikely to be with the keychain you created. Something went wrong, but somewhere else. We need at least logs to start. If that doesn't help, we'll need a binary to reproduce with machine access. You've likely set all the permissions for your binary in the local, but they're not set on the machine, and we need to understand what exactly needs permissions and for what.

[erik-bershel]

Since I'm running on a pipeline, I don't have access to the GUI session I guess, and, IIRC, remote sessions are subject to extra security measures on Mac, right?

What I mean is that the host is nothing more than a fully-fledged virtual machine where the agent runs in a user session. If you take a screenshot or record a video of a runner screen, you'll see a completely standard macOS interface, with application windows opening and closing as you run your pipeline.

[AlvaroPalmaAsteMicrosoft]

Hi @erik-bershel

Please find the requested file attached.

The application failing is unittests, the keychain it's trying to use is testagent_ut.keychain

MacOS14Logs.txt