Problem statement
Automatic‑Secret‑Rotation currently offers update-env to sync secrets from Vault/AWS into local environment variables by modifying shell configuration files . There is no first‑class support for securely persisting secrets in the local operating‑system’s credential store (e.g., macOS Keychain) when running the tool on a developer workstation.
Proposal
Add a feature to store rotated secrets in the macOS Keychain using the keyring crate’s apple-native backend. This crate provides a cross‑platform API for storing and retrieving secrets in the platform’s native keystore; enabling the apple-native feature compiles in the Keychain backend . keyring::Entry::set_password, get_password and delete_credential wrap the corresponding Keychain operations .
Implementation outline
• Cargo dependency – Add keyring = { version = "3.6.3", features = ["apple-native"] } to Cargo.toml for the CLI crate; compile with this feature only on macOS.
• Service & account names – Define a naming convention for the Keychain entry. A reasonable default is:
• service → the secret’s path (e.g. myapp/database)
• account → the environment variable name or key (e.g. DB_PASSWORD or password)
• New subcommand or flag – Introduce an update-keychain command (or a --keychain-service/--keychain-account option on existing commands) that:
1. Reads the secret value from the configured backend (Vault, AWS or file)
2. Writes the value into the Keychain via keyring::Entry::set_password
• Abstracted logic – Factor the Keychain update into a utility function (e.g. fn update_keychain(service: &str, account: &str, value: &str) -> Result<()>) so that auto‑rotation routines can call it after rotation.
• Documentation & tests – Update the README with usage examples (similar to the current update-env examples ) and add integration tests for Keychain functionality on macOS (mocking other platforms).
Rationale
• Security – Storing secrets in the Keychain leverages the OS’s secure storage and access controls.
• Developer experience – Developers often run asr locally to rotate secrets; writing secrets into shell config files exposes them in plain text. Keychain integration allows the same CLI to update secrets without exporting them into the environment.
• Cross‑platform future – While this issue targets macOS, the keyring crate also supports Windows (Credential Manager) and Linux (Secret Service) through other features , opening the door to similar support on those platforms.
Acceptance criteria
• Running asr update-keychain --service myapp/database --account DB_PASSWORD myapp/database on a macOS machine stores the secret in the Keychain and the value can be retrieved with security find-generic-password -s myapp/database -a DB_PASSWORD -w.
• The new flag is optional and does not break existing update-env behaviour.
• The feature is guarded by conditional compilation to avoid pulling in the macOS backend on other targets.
• Documentation is updated to describe how to enable and use Keychain support.
⸻
References: The existing update-env command updates .bashrc/.zshrc files the keyring crate requires enabling platform features and provides a simple API for setting and retrieving secrets
Problem statement
Automatic‑Secret‑Rotation currently offers update-env to sync secrets from Vault/AWS into local environment variables by modifying shell configuration files . There is no first‑class support for securely persisting secrets in the local operating‑system’s credential store (e.g., macOS Keychain) when running the tool on a developer workstation.
Proposal
Add a feature to store rotated secrets in the macOS Keychain using the keyring crate’s apple-native backend. This crate provides a cross‑platform API for storing and retrieving secrets in the platform’s native keystore; enabling the apple-native feature compiles in the Keychain backend . keyring::Entry::set_password, get_password and delete_credential wrap the corresponding Keychain operations .
Implementation outline
• Cargo dependency – Add keyring = { version = "3.6.3", features = ["apple-native"] } to Cargo.toml for the CLI crate; compile with this feature only on macOS.
• Service & account names – Define a naming convention for the Keychain entry. A reasonable default is:
• service → the secret’s path (e.g. myapp/database)
• account → the environment variable name or key (e.g. DB_PASSWORD or password)
• New subcommand or flag – Introduce an update-keychain command (or a --keychain-service/--keychain-account option on existing commands) that:
1. Reads the secret value from the configured backend (Vault, AWS or file)
2. Writes the value into the Keychain via keyring::Entry::set_password
• Abstracted logic – Factor the Keychain update into a utility function (e.g. fn update_keychain(service: &str, account: &str, value: &str) -> Result<()>) so that auto‑rotation routines can call it after rotation.
• Documentation & tests – Update the README with usage examples (similar to the current update-env examples ) and add integration tests for Keychain functionality on macOS (mocking other platforms).
Rationale
• Security – Storing secrets in the Keychain leverages the OS’s secure storage and access controls.
• Developer experience – Developers often run asr locally to rotate secrets; writing secrets into shell config files exposes them in plain text. Keychain integration allows the same CLI to update secrets without exporting them into the environment.
• Cross‑platform future – While this issue targets macOS, the keyring crate also supports Windows (Credential Manager) and Linux (Secret Service) through other features , opening the door to similar support on those platforms.
Acceptance criteria
• Running asr update-keychain --service myapp/database --account DB_PASSWORD myapp/database on a macOS machine stores the secret in the Keychain and the value can be retrieved with security find-generic-password -s myapp/database -a DB_PASSWORD -w.
• The new flag is optional and does not break existing update-env behaviour.
• The feature is guarded by conditional compilation to avoid pulling in the macOS backend on other targets.
• Documentation is updated to describe how to enable and use Keychain support.
⸻
References: The existing update-env command updates .bashrc/.zshrc files the keyring crate requires enabling platform features and provides a simple API for setting and retrieving secrets