[BUG]: varlockEnclave cannot read secrets created in keystore via secrets CLI

[bjesuiter]

varlock version

1.7.2

Steps to reproduce

On macOS:

1. Create a secret in Keychain using the secrets CLI.

   Example shape:

   secrets set <service-or-collection> <account-or-key> <value>

2. Configure Varlock to read the same secret through the native Keychain/enclave-backed resolver path (varlockEnclave / native local encryption / keychain resolver).

3. Run a Varlock command that resolves the value, for example:

   varlock load
   # or
   varlock run -- <command>

What is expected?

A secret created for Varlock's native Keychain/enclave workflow should be readable by Varlock when the service/account/key identifiers match.

What is actually happening?

Varlock's enclave/native Keychain path fails to read the secret when that secret was created by the external secrets CLI.

The underlying problem appears to be macOS Keychain access control: secrets created by the secrets CLI are scoped/authorized for the secrets CLI process, and are not automatically allowed to be read by other processes. This was confirmed by the user.

Possible solutions

1. Fix/update the Keychain item access control after creation so Varlock's process/native helper is allowed to read it. This appears to be possible in code already.
2. Preferably, avoid creating these Keychain secrets via the external secrets CLI at all. Instead, create/write them via the varlock CLI through Varlock's own daemon/helper, so the stored Keychain item is created with the correct access controls from the start and this mismatch cannot happen.

System Info

macOS Keychain / Varlock 1.7.2

Any additional comments?

Related but not the same:

• [Feature Request] MacOS keychain or OS native credential storage #458 added/discussed native OS credential storage / Secure Enclave support.
• [BUG]: Programmatic load() can leave daemon socket open after resolving keychain(...) #716 covered a daemon socket staying open after resolving keychain(...).
• [Feature Request] Encryption support #223 covered broader encryption support.

Those do not appear to cover the specific case where a secret created by the external secrets CLI cannot be read by Varlock's enclave/native Keychain integration due to Keychain access-control scoping.

[theoephraim]

What does your keychain resolver look like?
If you do ITEM=keychain(prompt) and select the secret what gets written out? Does it work?
What if you create a new secret through the prompt?

[bjesuiter]

yeah, ITEM=keychain(prompt) probably works,

but I'm in the process of migrating all my repos with .env files over to varlock + keychain and manually registering ALL my env vars sucks.
So i tasked my agent to help me with the migration by writing a script to move the env vars into keychain and register it correctly and i ran into this problem.

i'm currently vibe coding a "varlock keychain" subcommand namespace for handling this usecase less manual,
when I'm ready i'll give you a pr and I'd love to discuss whether you like the design or if we should improve something!

[theoephraim]

So is the issue just updating the ACL? Does the secrets command have anything to update it?
We could potentially add another flag like setAcl=true which would correct it and then update the env file to remove it.
Also could add some tools to help migrate a plaintext env file into keychain - much like we do with varlock encrypt --file.

Also just curious - any reason in particular you opted for keychain instead of the varlock() encryption? Multi-machine/backups?

[theoephraim]

Theres a larger discussion/design problem around writing secrets into plugin managed locations, as well as letting plugins provide CLI based functionality. Although since keychain is built-in, we can kind of ignore it for now.

Thanks for digging in on the CLI command :)

[bjesuiter]

So is the issue just updating the ACL? Does the secrets command have anything to update it? We could potentially add another flag like setAcl=true which would correct it and then update the env file to remove it. Also could add some tools to help migrate a plaintext env file into keychain - much like we do with varlock encrypt --file.

Also just curious - any reason in particular you opted for keychain instead of the varlock() encryption? Multi-machine/backups?

Yeah, the issue is basically just updating the ACL. But this has problems:

1. The current code in the Daemon CAN do such update, it does it when the user selects a keychain item which is not owned by the varlock daemon (based on ai analysis) => BIG PROBLEM: This uses a legacy keychain api (according to gpt-5.5.) which might get removed by apple at any point.

2. Also, i find it suspicious and not really secure that a random process (from the view of keychain) can update the acls to view secrets of another process, so I'd understand apple that they'd want to remove such legacy APIs.

As I said, my preferred workflow would be:
use varlock directly to import existing .env secrets based on a .schema.env file which provides the infos whcih env vars are secrets and which are not.

For why i chose keychain and not local:
I develop with two macs often, i have openclaw installed on my mac mini and sometimes i checkout repos from github so openclaw can work on them on my mac mini, while at other times i edit the same repo directly on my mac book pro.

Additionally, i'd like to have linux compat for my secrets workflow, but therefore I'd have to switch to a different secret store alltogether which is too much work right now and I might dig into this later.

[bjesuiter]

Theres a larger discussion/design problem around writing secrets into plugin managed locations, as well as letting plugins provide CLI based functionality. Although since keychain is built-in, we can kind of ignore it for now.

Thanks for digging in on the CLI command :)

yeah, I can see that this is a larger discussion/design problem. having plugins extend the cli would be kinda nice, but also more work in the core. is this discussion in your discord? I might join it if you want :)

[bjesuiter]

For now, since keychain is a varlock-native implementation, i find it okay to have a "varlock keychain" namespace in the cli to manage keychain specific functionality.

here is the pr, i'm currently reviewing it and polishing it for your review :)
#820

[theoephraim]

Sounds good! Yeah ill loop you in when we do start talking about it.

I think when that command updates the ACL you do have to approve it - so doesn't seem that crazy, but if there's a newer method, then that makes sense.

We are going to likely offer our own shared vault stuff at some point to help with the multi-device and multi-user secrets workflows. Likely will make it very easy to onramp from other plugins/storage.

I'll try to have a deeper look at this PR tomorrow.

Thanks! 🧙‍♂️

[bjesuiter]

Ah, a third problem about the ACL thingy is that it's not obvious how to fix the ACL to allow VarlockDaemon, since i as a user don't know where that daemon binary lives per default.
So I can't update the ACLs manually easily, therefore this should be handled by varlock ^^

Yes, have a good night and thanks for answering so quickly! Will finish the pr for you an then also stop for today :)

[bjesuiter]

@theoephraim small ping for the review, since I'd like to use that feature without needing to release a custom varlock build for myself 😅

As I said I want to reset my macOS and this conversion of my repos to varlock is an integral part because I don't want to restore the envs for 10ths or even 100ths of repos 😅

But no pressure (really!), if you don't have time tomorrow or Friday please say it and I'll go the route of cutting a release for myself or using some hotfix solution 🤗

[theoephraim]

will get to it today!

[bjesuiter]

feature merged in this pr: #835 (comment)

One note: the import and set function work great, but the fix-access is still not nice in this workflow. It adds the ACLs for the Daemon, but this does not prevent macOS from showing permission prompts when reading these secrets from keychain with the additional ACL.

So i made a new PR which changes the fix behavior to clone the secrets via a temp secret, which makes the varlock daemon the owner of the secret and avoids further permission prompts.
#847

I'd keep this issue open until the second PR is reviewed / resolved

[theoephraim]

If a user had an existing secret with acl connected to another app, would this new behaviour remove the access of that app?

[bjesuiter]

I'll check this!