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

Open
  • Is something wrong?
#819 16 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #820 by @bjesuiter — closed without merging

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
typescript
Domain
backend, security

Research direction

Start by reviewing the closed, unmerged pull request #820 and the related discussions in #458, #716, and #223 to see what has already been tried. Then locate the varlockEnclave or native Keychain resolver and the Varlock CLI or helper path that writes secrets; the issue names no file or test. Done means a secret created through Varlock can be read through the enclave path with the matching service and account identifiers.

Written by the indexing model from the issue text.

Description

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:

  • #458 added/discussed native OS credential storage / Secure Enclave support.
  • #716 covered a daemon socket staying open after resolving keychain(...).
  • #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.

Dominant language
TypeScript
Stars
4.9k
Forks
140
Avg merge
2d 3h
Merged PRs (30d)
35

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmno-dev/varlock

All issues in dmno-dev/varlock

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.