Hi,
I’d like to be able to list the defined usernames without having to authenticate against the repository. I can read them anyway with read access to the files of the repository ( the json files in the keys directory ). However, if the repository is located on a sftp or s3 backend, it gets harder to do and since the restic binary already implements the backend connection …
The only way to get the list of usernames now is to use restic key list , which requires authentication and that’s hard to do if you do not or no longer know which usernames were defined on the repository …
Or is there an alternative ?
Thanks,
Peter.
IMO it is waste of time to implement it in restic. Very exotic feature it would be:)
It is not something anybody uses often (if ever). If you have to look into some file content it can be handled outside of restic - as you already mentioned.
What for? I don’t really understand the use case here. The direction is anyways to get rid of the unencrypted key metadata: Drop unencrypted key metadata by MichaelEischer · Pull Request #5303 · restic/restic · GitHub .
Well, we’re trying to implement a envelope encryption style - system with restic, ref: Envelope encryption | Cloud Key Management Service | Google Cloud Documentation .
Since restic uses one masterkey that never changes, we will be creating a new repository for every full backup. This is necessary because any username/password compromise would compromise the entire repository as it is very easy to dump the masterkey.
We use Vault to hold the KEK, generate DEK’s and encrypt them. As a compromise, we thought a username/password combination would be substitute for a DEK so we thought we could use the encrypted DEK as the username and the DEK itself as the password.
Every backup done on the repository would rotate the ‘DEK‘ = replace the current username/password combination.
But this all works if we can list out the usernames currently defined on the repository. This can be done from the files, but as I gather, this will become impossible in the future.
Another option was to just rotate the password. But with the high number of repositories with some of them on immutable storage, changing them all every time would also not be feasable. And then it would come down to trying them one by one on older repositories, which takes time. The alternative we thought of, was using a username with a timestamp or generation number but again, we need to be able list out the usernames.
Or maybe I’m just missing the point entirely, which is a very real possibility.