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.
Based on that description, you already need some way to modify the keys created by restic (or how are you gonna set the username?). With that in place there’s nothing that would prevent you from still using the username field (future restic versions probably just won’t set it, but keys with such a field would still be loaded).
But I think you’re actually asking for something else: a way to store (unencrypted) auxiliary data together with a key (there should be a thread/issues that ask for this in regards to GPG). Then this auxiliary data can be passed to the password command.
For now the cleanest option would be to place a file with the encrypted DEK as a separate file into the repository, although you then need a way separate from restic to read that file back.
We would access the repository with the old username/key, add a new username/key, connect with the new username/key and remove the old one.
What do you mean future restic versions no longer use username ? How would they know which key to check ? Or would they just try them all ?
You are correct in your assessment, we do need a way to store unencrypted data with a key. We thought of adding a file alongside the repository but we need a separate way to access it. So we thought of (ab)using the username so we could just use the restic backend code.
Adding the requested username as a parameter to the password program would be very helpful also.
The username is stored unencrypted in the keys, thereby effectively leaking it. See Drop unencrypted key metadata by MichaelEischer · Pull Request #5303 · restic/restic · GitHub for the current PoC. That PR replaces the user+hostname with an encrypted label.
I’m not entirely sure what would required as a replacement for you. Probably some unencrypted auxiliary data field that’s passed to the password command as an environment variable. And maybe some unencrypted label to be able to easily identify keys. Feel free to add your usecase to the PR / the issue linked there.
Every backup done on the repository would rotate the ‘DEK‘ = replace the current username/password combination.
What for?