Use system keyring to obtain passwords
It would be possible to store the password given to rad auth into the system keyring.
The keyring would then be unlocked automatically on login and makes the password available via
https://lib.rs/crates/libsecret.
I use a work around with a small script called rad_node_start that reads:
#!/usr/bin/env bash
RAD_PASSPHRASE=$(secret-tool lookup radicle client) rad auth
RAD_PASSPHRASE=$(secret-tool lookup radicle client) rad node start
The password has been set before as a one shot with:
secret-tool store --label='Radicle' radicle client
wich prompts for the password and puts it in the store. The attribute ‘radicle’ and value ‘client’ could be freely choosen.
Wouldn’t using the already-existing system keyring’s key for Radicle be even better ? A Radicle key is just an SSH key at the end of the day.
This is exactly what I propose. libsecret is a rust library that wraps gnome libsecret which allows using to store passwords conforming to freedesktop specification.
What I sketched is just a work around using the CLI of libsecret.
Hmm, libsecret stores the password you will use to unlock the SSH key which is stored in ssh-agent. Of course you could directly add the ssh-key to the keyting (which works) thereby not requiring rad auth, but then you are back to be required to need to enter the password at node start up.
z6MkrUBVfHjFuqVBZ6u94uapJTpktmWgFqW2bYwwSav7Z5k9 wrote:
I thought the ssh-agent interface only exposed the public key? and mechanisms for challange response for authentication. So for cases where radicle needs the private key,
for signing for example1, the ssh-agent protocol wouldn’t be enough.Where as the secretsservice protocol, allows you to get the stored secret itself.
Though I’d imagine, if your ssh key is password protected, and you stored it as such, you would still need a password to decrypt it after fetching it from secretsservice.
So the password itself will need to be stored as a secret somewhere.
If you’d rather not implement the protocol directly in the cli executable, you could perhaps take a leaf out of git’s book, and go a credential helper route? Allow some configuration of an executable so that radicle-cli will call out to said configured executable which returns the credential in some well known secure-ish2 manner.
Then third parties can implement what ever they want in order to provide ssh key password retrieval, and radicle doesn’t need to implement the protocol itself.
And if left unconfigured, radicle just does the current behaviour.
Though that is all assuming I’m not wrong about the SSH Agent since if it’s interface does provide all the functions radicle needs to do what it needs, then yeah, why rely on anything else at all.
Seems I should look things up before opening my mouth. ssh-agent does allow signing, and I don’t know enough about the internals of radicle to know what other private key operations are needed outside of signing.
with that said, looking at an example “shell script” git-credential-helper, it just outputs the values to stdout (See below). Whether you guys thinks that’s suitable or not is another question, and I have no idea if git has other mechanisms for returning the results.