Rclone seems to have a feature to encrypt the entire configuration file. I don't want that. Only the passwords / credentials for the various remotes should be protected. The flag `--password-command` also seems related to the password for a whole encrypted config, rather than a specific remote.
I already have the credentials for remotes in a password manager. Instead of configuring the password directly, I would like to configure a command that rclone calls when connecting to a specific remote, to get the password for that remote.
The advanced configuration already has an option "bearer_token_command". This seems quite similar to what I want, just for a bearer token instead of the password.
It is owned by that process user and have permissions:
-r--------
if your user (or root) is compromised then not sure what rclone option will help you. As I guess this user has the right to run your "get-password" program.
And you can always encrypt your config file... and achieve what you want. But just maybe not in the way you like the most:)
As I guess this user has the right to run your "get-password" program.
My get-password program prompts the user for confirmation. There is a real additional layer of security there. A compromised local user is indeed a big problem. Still, I take care that this doesn't also expose credentials for other security boundaries. Defense in depth.
I guess I'll try to make the encrypted config work for me. But it really is an absurd solution. There is no need to encrypt the whole config. Only credentials need to be secured. And securing credentials is the job of a password manager, this logic shouldn't be reimplemented by every random CLI tool under the sun. This entire feature is just doing the job of a password manager really, really badly. The only secure way to use this feature is with the --password-command flag, which requires a separate password manager anyway, and the official docs even provide examples of how to do so. At which point, the user is left to wonder why rclone can't just retrieve the relevant credentials directly, instead of making the completely unnecessary detour of encrypting the whole config.
I keep my configuration in a dotfiles repo. I guess I'll have to check in my rclone config in encrypted form? That's a big no-no to me, but I don't see another way.
You are right. And highly likely that if rclone was designed again from the scratch without taking into account any existing legacies what you suggest would be much more elegant approach.
IMO however where we are today is that some design choices look cumbersome but do their job. It is always a question now what to spend time on... ironing some existing feature to make it more logical and "nice" or focus on some more pressing matters - like bugs fixing and new things.
I am sure that if somebody implements what you suggest it will be welcomed and quickly incorporated into rclone. Only question is who will need it so much that will spend time or/and money:) Or maybe it is not such a big thing to do? Somebody would have to spend some time investigating.
Now as you already suggested it - maybe some passerby will have a go on it...
PS. Thank you for pointing at insecurities in cmd and environment variables. It made me to reconsider some of my "legacy" knowledge:)