Different passphrases for different repositories? #281
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#281
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Loving borgmatic, thanks so much for it. Today was another of these moments where I realise it: the ability to back up to multiple repositories by just adding one extra line in "repositories:" section in Borgmatic config file was magic. Mind blown :) Thanks!
The downside: The way the config file is, it seems all repos mentioned in the config must use the same passphrase, which sounds not ideal security-wise. I could not find a way to specify a different passphrase for each repository encrypted in
repokey
mode.Is there a way to specify different passphrases for different repositories, in the same config file, please?
I'm glad to hear borgmatic config can sometimes be magical. 😄 I totally get what you're saying though about the repositories in a configuration file having all the same configuration.
Right now, if you want to specify different passphrases per repository, you'd have to declare each repository in a separate borgmatic configuration file. Then, you can vary the settings in each one as you like. And if that causes too much duplication, see the discussion about includes on that page.
Also, if you'd like to see some prior discussion on the general topic of varying configuration per repository in a configuration file, check out this ticket: witten/borgmatic#73
Note that I'm happy to look at ideas for better ways to do this. And/or hear about any challenges you face with the include approach. Let me know what you end up doing.
Oh, it is definitely magical :)
Thank you very much @witten! I had missed #73 and includes, I will check them out and report!
Sounds good!
Alright, if I understand correctly, because here every YAML key would be the same except for that containing the passphrase, we would need to have multiple includes. Completely feasible, but a bit messier than ideal.
That's no big deal, though. The more I think about my setup, the less I am bothered by having twice the same passphrase. If I am in a situation where the attacker has access to the passphrase of one of the repos, I am already in deep trouble and not protected by having another passphrase.
So nevermind this request, and thanks for the very helpful answer and all the awesome work!
Okay! If this sort of need comes up again, please do let me know about it. Includes work well for certain situations, but as you've discovered, not for all of them.
I've been noodling on this general problem, because it's come up in other contexts (even if you don't need it solved right now). What if the include merging feature did deep merging instead of shallow merging? That would allow you to do something like this:
And then you could have as many instances of that as you needed:
The idea is that even if
common_config.yaml
has otherlocation
orstorage
options set, they would still get carried through after the include due to the deep merging.Thoughts? Would this still be too cumbersome?
I think I have a situation where being able to set per-repo passphrases would be useful/important.
My config takes a snapshot of an LVM logical volume, mounts the snapshot, backs up the snapshot to two separate repositories, then cleans up the snapshot.
I don't want to use the same passphrase for both repos. If an attacker obtains the passphrase, it becomes much easier for them to corrupt both repos (assuming the passphrases are not saved inside the backups).
I also want to save the same snapshot to both repos. If I use separate configs, then each config will take a snapshot when it is its turn, leading to slightly different snapshots/backups.
I have switched to using
before_everything
instead ofbefore_backup
to take the snapshot, but this feels like a workaround instead of a real solution.Another workaround I considered was using
encryption_passcommand
to return a different passphrase depending on the repo, but it doesn't appear that borg or borgmatic pass this information to the command (or set it in an environment variable). I understand from borg's perspective it is only operating on one repo and so the user can hardcode it into the command, and from borgmatic's perspective since borg doesn't support this then there is not much else it can do, so this appears to be a non-starter.Thinking a bit more,
before_everything
works for the simple case, but if there are other configs to be processed, taking snapshot(s) before everything starts may not be ideal/feasible.If I'm understanding this correctly, it sounds like the basic need/ask is to be able to run borgmatic hooks "around" some particular Borg invocations that borgmatic kicks off—but not necessarily all Borg invocations. In this case, you want to run an LVM snapshot hook before particular repositories are backed up, which by its nature requires multiple Borg invocations.
And an additional ask is to be able to set a separate passphrase per repository. Which right now is only supported by separate borgmatic configuration files... Whether or not there's some configuration merging in place to cut down on duplication.
So am I correct in assuming that having multiple different configuration files (one per repository + passphrase) would be sufficient for your needs, assuming there was a way to run the hooks at the right time?
Thanks!
Related issue: Native LVM support in borgmatic
You could say that, though I think there is semantic / mental model difference between "taking one backup and sending it to multiple places" and "taking multiple backups that contain the same files" (where one config "equals" one backup). Even though there may be no functional difference, personally I find the former to be more intuitive.