Skip to content

apple: silent empty-password unlock of login keychain on open#69

Merged
jgowdy-godaddy merged 1 commit intomainfrom
fix/macos-keychain-ci-unlock
Apr 17, 2026
Merged

apple: silent empty-password unlock of login keychain on open#69
jgowdy-godaddy merged 1 commit intomainfrom
fix/macos-keychain-ci-unlock

Conversation

@jgowdy-godaddy
Copy link
Copy Markdown
Contributor

Summary

  • After Threat-model hardening pass: envelope, meta HMAC, bridge, process, adapter #68 the Swift bridge opens the login keychain by explicit absolute path and routes all SecItem* calls through it via kSecUseKeychain/kSecMatchSearchList.
  • On GitHub Actions macos-latest runners the login keychain is re-locked between jobs. With an explicit locked handle in hand the next SecItemAdd blocks indefinitely waiting for a GUI unlock prompt that never arrives — hanging npmenc CI for 30+ minutes.
  • Fix: after SecKeychainOpen, attempt a silent unlock with an empty password (SecKeychainUnlock(kc, 0, nil, true)). Interactive dev sessions already have the keychain unlocked, so this is a no-op. CI runners get their keychain unlocked without any prompt.
  • If the keychain has a real password the unlock silently fails and the subsequent op surfaces the real error — deliberately no fallback to avoid masking legitimate failures.

Test plan

  • cargo build -p enclaveapp-apple --features signing,encryption
  • cargo test -p enclaveapp-apple --features signing,encryption --lib — 44 pass, including real-keychain keychain_wrap::tests
  • cargo clippy -p enclaveapp-apple --features signing,encryption --all-targets -- -D warnings
  • Watch npmenc Skip co-author trailers in CLAUDE.md #18 macOS CI after merge — expected to drop from 30+ min hang to under 2 min.

After #68 the Swift bridge opens the login keychain by explicit
absolute path and routes all `SecItem*` calls through it. On
GitHub Actions `macos-latest` runners that keychain is locked
between jobs (it was unlocked once with an empty password at
image-provision time). With the explicit handle in hand the next
`SecItemAdd` blocks indefinitely waiting for a GUI unlock prompt
that never arrives, hanging the job.

Fix: after `SecKeychainOpen`, attempt a silent unlock with an
empty password. Interactive dev sessions already have the
keychain unlocked so this is a no-op; CI runners get their
keychain unlocked without any prompt. If the keychain has a
real password the unlock silently fails and the subsequent
operation surfaces the real error — we deliberately do not
mask it with a fallback.
@jgowdy-godaddy jgowdy-godaddy merged commit d9b520b into main Apr 17, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants