mirror of https://github.com/borgbackup/borg.git
commit
8f2d80e60b
|
@ -37,6 +37,10 @@ Under these circumstances Borg guarantees that the attacker cannot
|
|||
The attacker can always impose a denial of service per definition (he could
|
||||
forbid connections to the repository, or delete it entirely).
|
||||
|
||||
When the above attack model is extended to include multiple clients
|
||||
independently updating the same repository, then Borg fails to provide
|
||||
confidentiality (i.e. guarantees 3) and 4) do not apply any more).
|
||||
|
||||
.. _security_structural_auth:
|
||||
|
||||
Structural Authentication
|
||||
|
@ -369,3 +373,16 @@ while libssl implements TLS and related protocols.
|
|||
The latter is not used by Borg (cf. `Remote RPC protocol security`_, Borg itself does not implement
|
||||
any network access) and historically contained most vulnerabilities, especially critical ones.
|
||||
The static binaries released by the project contain neither libssl nor the Python ssl/_ssl modules.
|
||||
|
||||
Compression and Encryption
|
||||
==========================
|
||||
|
||||
Combining encryption with compression can be insecure in some contexts (e.g. online protocols).
|
||||
|
||||
There was some discussion about this in `github issue #1040`_ and for Borg some developers
|
||||
concluded this is no problem at all, some concluded this is hard and extremely slow to exploit
|
||||
and thus no problem in practice.
|
||||
|
||||
No matter what, there is always the option not to use compression if you are worried about this.
|
||||
|
||||
.. _github issue #1040: https://github.com/borgbackup/borg/issues/1040
|
||||
|
|
|
@ -201,15 +201,28 @@ copy just in case something goes wrong during the recovery. Since recovery is do
|
|||
deleting some files, a hard link copy (``cp -al``) is sufficient.
|
||||
|
||||
The first step to reset the repository to transaction 5, the last uncompromised transaction,
|
||||
is to remove the ``hints.N`` and ``index.N`` files in the repository (these two files are
|
||||
always expendable). In this example N is 13.
|
||||
is to remove the ``hints.N``, ``index.N`` and ``integrity.N``files in the repository (these
|
||||
files are always expendable). In this example N is 13.
|
||||
|
||||
Then remove or move all segment files from the segment directories in ``data/`` starting
|
||||
with file 6::
|
||||
|
||||
rm data/**/{6..13}
|
||||
|
||||
That's all to it.
|
||||
That's all to do in the repository.
|
||||
|
||||
If you want to access this rollbacked repository from a client that already has
|
||||
a cache for this repository, the cache will reflect a newer repository state
|
||||
than what you actually have in the repository now, after the rollback.
|
||||
|
||||
Thus, you need to clear the cache::
|
||||
|
||||
borg delete --cache-only repo
|
||||
|
||||
The cache will get rebuilt automatically. Depending on repo size and archive
|
||||
count, it may take a while.
|
||||
|
||||
You also will need to remove ~/.config/borg/security/REPOID/manifest-timestamp.
|
||||
|
||||
Drawbacks
|
||||
+++++++++
|
||||
|
|
Loading…
Reference in New Issue