feat(cli): replace keytar with cross-keychain for token storage

[gnugomez]

keytar is archived and unmaintained, for now the approach was to fallback to plaintext if for whatever reason the system store fails to bind. That was a likely situation given the unmaintained/archived status of such dependency.

This patch changes the store library to use a cross-keychain, a library that's in active development and should work better cross-platfom-wise.

The old implmentation was already failing to me in macos (in dev environment) and falling back to plain text, I'm not sure about other systems, the tool already migrates plaintext secrets to system keychain as soon as it's available.

A good test would be to run since this command only interacts with the store and not with the registry, if it replies with unknown namespace it's likely not finding the old token.

In macOS is working fine:

[gnugomez]

note: https://github.com/magarcia/cross-keychain is not being so well-maintained, for the native backends is using https://github.com/Brooooooklyn/keyring-node, that is a project that looks pretty up to date. So cross-keychain provides a wrapper API around this rust bindings.

[netomi]

whether its well maintained is hard to decide from the commit history. Both projects mainly update dependencies since a while, so its clearly in maintenance mode. I would still go with cross-chain as the overall source is pretty much polished.

[netomi]

I tested it on my linux system (Ubuntu 24.04) and it worked well.

Verified with

secret-tool lookup service ovsx username <namespace>

that the PAT I stored for a namespace is in the secret service.

The library supports different backends included an encrypted file fallback if all the other methods do not work. So I think we should utilize that and use that instead of our own poor mans file storage.

You can detect which backend is used with the diagnose method, and specify the location of the secret file.

That way we could also get rid of the unsecure plan text File storage backend as a fallback.

[gnugomez]

@netomi yeah, I agree - I'll take a look and apply that change too

[gnugomez]

hey @netomi I added a change to fallback to the encrypted cross-keychain's backend implementation, as a last resort I'm leaving the plain-text version.

also the OVSX_STORE=file will now use the encrypted store.

by default this encrypted store Encrypted file storage (AES-256-GCM) is creating an encryption key in ~/.config/keyring/file.key and storing the secrets at ~/.local/share/keyring/secrets.json the paths are slightly different in windows.

if the user was falling-back to the plain-text because the system one was not working for them, this store will be migrated to the encrypted one if working.