Research macOS Keychain access patterns for version-resilient security helpers

[djbclark]

Context

macOS apps such as OpenUsage can prompt the user to re-allow Keychain access after an app version bump, even when the app remains installed at a stable path. The likely cause is that Keychain access control can be associated with the application code signature / designated requirement and/or binary identity, so a newly signed release no longer matches the prior ACL entry.

Observed locally:

• OpenUsage is installed through Homebrew at /Applications/OpenUsage.app.
• Bundle identifier: com.robinebers.openusage.
• Current signing identity: Developer ID Application: SUNSTORY LLC (QC3D3H67V9).
• The installation path is already stable, so path stability alone does not appear sufficient.
• Repeated version-bump prompts are the user-visible symptom.

User-side techniques to investigate

Research and evaluate approaches that do not require upstream changes, including:

• Keychain Access Control configuration that permits all applications for deliberately selected items, versus narrowly allowing a stable designated requirement.
• Whether security CLI or a local helper can safely inspect and repair access control entries after an update without exposing secret values.
• A local post-install / update hook or LaunchAgent that detects a changed app code requirement and performs a safe, user-approved migration.
• Deleting and recreating affected items as a fallback, while preserving least-privilege and avoiding accidental credential loss.
• Whether a wrapper/helper with a stable code signature, bundle identifier, keychain access group, or other durable identity can mediate access across app updates.
• Trade-offs among convenience, least privilege, malware exposure, notarization, and macOS version compatibility.

Broader research request

Use the findings to enhance or replace our security helpers for data providers. The goal is a reusable local security-helper pattern that can tolerate legitimate provider/app updates without recurring manual “Always Allow” prompts, while keeping credentials in the Keychain and preserving strong access boundaries.

Acceptance criteria

• Document the actual Keychain behavior and which identity fields survive normal signed app updates.
• Prototype at least one user-side mitigation on macOS without modifying OpenUsage upstream.
• Define a secure migration/repair workflow that never logs or asks the user to paste secret values.
• Compare the current security helpers for our data providers against the researched pattern.
• Recommend whether to enhance the existing helpers or replace them, with explicit security and operational trade-offs.
• Include rollback and recovery guidance for accidentally broadened or damaged Keychain ACLs.

Notes

Do not assume that a stable /Applications path is enough. Validate behavior against real Keychain item metadata and code-signing requirements. Prefer local/user-side changes over upstream changes where practical.