Linux secret-store probe runs secret-tool --version, which libsecret does not support, so the keyring is never detected

Linux secret-store probe runs secret-tool --version, which libsecret does not support, so the keyring is never detected

File at: https://github.com/elastic/cli/issues

Summary

On Linux, @elastic/cli never uses the Secret Service keyring even when libsecret's secret-tool is installed and a working D-Bus session with an unlocked keyring is present. Every command that stores a credential falls back to inline storage and prints:

Warning: No OS secret store is available; credentials will be written inline to the config file (chmod 0600).

Cause

LinuxSecretServiceStore.probe() in dist/config/secret-store.js runs:

_execSync('secret-tool --version', execOpts(2_000));

secret-tool has no --version option. It prints its usage text and exits 2, so the probe throws and the store is marked unavailable. The CLI then tries PassStore (pass version), which is usually absent, and ends on NoopStore.

$ secret-tool --version; echo "exit=$?"
usage: secret-tool store --label='label' attribute value ...
       secret-tool lookup attribute value ...
       secret-tool clear attribute value ...
       secret-tool search [--all] [--unlock] attribute value ...
       secret-tool lock --collection='collection'
exit=2

The put, lookup, and clear calls themselves work fine. Only the availability probe fails, so reads of an existing $(secret_service:...) reference succeed while writes never produce one.

Environment

Reproduction

sudo apt install libsecret-tools
printf x | secret-tool store --label=probe service probe account probe && echo "keyring works"
elastic config context add demo --cloud-url https://api.elastic-cloud.com --cloud-api-key "$KEY" --json

Expected secrets[0].storage to be secret_service. Actual: inline, plus the warning above.

Confirming the diagnosis

Placing a wrapper named secret-tool earlier on PATH that exits 0 for --version and otherwise execs the real binary makes the same command report "storage":"secret_service", writes $(secret_service:elastic-cli/demo:cloud.auth.api_key) into the config, and creates the keyring entry. Nothing else changes.

#!/usr/bin/env bash
[ "$1" = "--version" ] && { echo "secret-tool shim"; exit 0; }
exec /usr/bin/secret-tool "$@"

Suggested fix

Replace the --version probe with something secret-tool actually supports. Options, in order of preference:

1. Check that the binary exists (command -v secret-tool or which) and let a failed put trigger the inline fallback. This matches how reads already behave.
2. Do a round trip: secret-tool store a throwaway entry, then secret-tool clear it. This also verifies the D-Bus session and unlocked keyring, which a binary check does not.

Note that secret-tool lookup on a missing item exits 1 and secret-tool search exits 0 even with no D-Bus session, so neither is a reliable availability signal on its own.

Impact

Every Linux user of the CLI is silently downgraded to plaintext credentials in ~/.elasticrc.yml, and the warning text tells them to install a store they may already have.