cfl & jtk now requiring keystore even when config file exists

[aaron-baff-ad-net]

I find with cfl version 1.0.45 (commit: e10c2eae89dfa9e5852494050058053b1ce4f4a1, built: 2026-05-18T13:14:42Z), on Linux (Debian Stable with KDE), even though I have a previously working and existing ~/.config/cfl/config.yml, whenever I use cfl now it prompts to use the system keystore, instead of just using what is in the config file. jtk doesn't prompt for keystore, works just fine.

EDIT: Now jtk does it as well. This doesn't work well for my workflow, my agent just has it fail, the system never prompts me to try and unlock.

@rianjs this is an issue. I get why using a system keystore is more secure, but now you're locking out significant fully automated things that might be running where I don't HAVE a keystore (potentially) or running headless without me there to unlock the keystore. I'm not even getting a keystore prompt except when I manually run it. When Claude Code runs it, it doesn't give me that prompt.

This is on KDE Plasma, Debian Stable.

[rianjs]

Thx Aaron. I will noodle on it.

[rianjs]

The goal was to aggressively get people to not have plaintext secrets on their machines. I realize that's how a lot of SSH keys are stored today, which isn't great. One of my ongoing fears as I watch fast-moving supply chain attacks occur is just how fast the threat landscape moves today, and often incidents have significant blast radii.

I maintain these CLIs primarily for my own use cases, and "not having plaintext secrets on user machines" is a pretty big priority in that world. We kinda yolo'd these CLIs up back in January, and I've been trying to get a bit more disciplined around a great many things, with security kinda being the forefront of that.

I wonder if there's like a i-solemnly-swear-that-i-want-this-in-plaintext flag or something I can add that will do something reasonable, and put the credentials next to the config file(s).

Hrm.

[aaron-baff-ad-net]

Completely on board with aiming to have better practices and discipline around these sorts of things. I think perhaps having an "credentials provider", which can be system keystore as default, sure, but also could be, let's say, KeePassXC, or a secrets provider (hmm...I should investigate that...) or, as a last ditch "I really really mean it and I know what I'm doing" allow the plain text.

[rianjs]

We actually have a piece of this via credstore — the auto-fallback is deliberately conservative (only when there's no D-Bus session bus at all) because I didn't want a locked keyring to silently downgrade to a less-secure store.

For your headless case specifically: loginctl enable-linger + gnome-keyring-daemon (or KeePassXC, which speaks the Secret Service D-Bus API natively) as a systemd --user service is the canonical setup: works today, no CLI changes needed. I think that would solve your case for now, maybe?

I'm considering migrating to https://github.com/ByteNess/keyring/ -- it's a fork of the 99designs thing that's actually getting updates, including CVE fixes. (I could have sworn I had that as an issue filed somewhere... I'll have my robot do that in a minute...) -- and that supports more backends. (e.g. 1Password). However the API for the CLIs still don't expose a preferred backend, despite credstore supporting it internally. That's actually a pretty reasonable thing to want, too. Maybe "plaintext" could be a preferred backend, but typing that makes me die a little bit inside.