mirror
/
borg
mirror of https://github.com/borgbackup/borg.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #3697 from ThomasWaldmann/backports-17 

Backports 17
This commit is contained in:
TW 2018-03-17 21:27:09 +01:00 committed by GitHub
parent d7ec959ce2 2f443cae73
commit 8f2d80e60b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 33 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/internals/security.rst
View File

@ -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

19
docs/usage/notes.rst
View File

@ -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
+++++++++