This feature allows multiple repositories to share deduplication-relevant secrets (id_key and chunk_seed) while maintaining secure, independent encryption keys.
`borg key export-related-secrets <REPO> <SPATH>` to export the secrets to a JSON file.
`borg init --import-related-secrets <SPATH> <REPO>` to initialize a new repository using the secrets from the JSON file.
Both repositories must use the same chunk id algorithm (both HMAC-SHA256 or both BLAKE2b).
If you create related repositories with borg 1.4.x, you can later transfer their archives
to one or multiple related new borg2 repositories without breaking deduplication.
But please note that we might remove BLAKE2b support for new borg2 repos, see #8867,
so this might only work for HMAC-SHA256 in the end.
Consolidate key backup documentation into `borg key export` and reference
it from Quickstart and FAQ to avoid duplication and inconsistency.
Clarify that while `repokey` or `authenticated` mode stores the key in the
repo, a separate backup is still recommended to protect against repository
corruption or data loss.
Backport from master: Make clear that absolute paths always go into the matcher as if they are relative (without leading slash). Adapt all examples accordingly.
The previous sample for creating a ~/.borg-passphrase file creates it first and then chmod's it to 400 permissions. That's probably fine in practice, but means there's a tiny window where the passphrase file is sitting with default permissions (likely world readable, depending on the system umask).
It seems safer to first change the umask to remove all group & world bits (0077) _before_ creating the file. To be polite and avoid messing with the user's previous umask, we do this in a subshell. (Note that umask 0077 leads to a mode of 600 rather than the previous 400, because removing the owner write bit doesn't seem to buy much since the owner can just chmod the file anyway.)
https://github.com/borgbackup/borg/pull/6188#discussion_r794752672
> Well, guess one could also use max(list of trusted nonce values).
>
> The real issue is if you have lost all or some of the trusted
> (client side) nonce values and you also have reason to not trust the
> server side nonce, because someone might attack you on the server.
It was unclear that the user _only_ needs to have borg installed on a remote system to use client/server mode. Hopefully this change makes it apparent that the user doesn't start anything on the remote system themselves.
