#281 Different passphrases for different repositories?

Closed
opened 1 month ago by jucor_ · 6 comments
jucor_ commented 1 month ago

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?

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?
witten commented 1 month ago
Owner

I'm glad to hear borgmatic config can sometimes be magical. :smile: 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: #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.

I'm glad to hear borgmatic config can sometimes be magical. :smile: 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](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/). Then, you can vary the settings in each one as you like. And if that causes too much duplication, see the discussion about [includes](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#configuration-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: https://projects.torsion.org/witten/borgmatic/issues/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.
witten added the
question / support
label 1 month ago
jucor_ commented 4 weeks ago
Poster

Oh, it is definitely magical :) Thank you very much @witten! I had missed #73 and includes, I will check them out and report!

Oh, it is *definitely* magical :) Thank you very much @witten! I had missed #73 and includes, I will check them out and report!
witten commented 4 weeks ago
Owner

Sounds good!

Sounds good!
witten added the
waiting for response
label 4 weeks ago
jucor_ commented 4 weeks ago
Poster

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!

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!
witten removed the
waiting for response
label 4 weeks ago
witten commented 4 weeks ago
Owner

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.

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.
witten commented 4 weeks ago
Owner

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:

<<: !common_config.yaml
location:
    repositories:
        - first_repo.borg

storage:
    encryption_passphrase: phrase1

And then you could have as many instances of that as you needed:

<<: !common_config.yaml
location:
    repositories:
        - second_repo.borg

storage:
    encryption_passphrase: phrase2

The idea is that even if common_config.yaml has other location or storage options set, they would still get carried through after the include due to the deep merging.

Thoughts? Would this still be too cumbersome?

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: ```yaml <<: !common_config.yaml location: repositories: - first_repo.borg storage: encryption_passphrase: phrase1 ``` And then you could have as many instances of that as you needed: ```yaml <<: !common_config.yaml location: repositories: - second_repo.borg storage: encryption_passphrase: phrase2 ``` The idea is that even if `common_config.yaml` has other `location` or `storage` options set, they would still get carried through after the include due to the deep merging. Thoughts? Would this still be too cumbersome?
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.