This section provides information about security and corruption issues.
A flaw in the cryptographic authentication scheme in Borg allowed an attacker to spoof the manifest. The attack requires an attacker to be able to
This vulnerability does not disclose plaintext to the attacker, nor does it affect the authenticity of existing archives.
The vulnerability allows an attacker to create a spoofed manifest (the list of archives). Creating plausible fake archives may be feasible for small archives, but is unlikely for large archives.
The fix adds a separate authentication tag to the manifest. For compatibility with prior versions this authentication tag is not required by default for existing repositories. Repositories created with 1.0.9 and later require it.
Steps you should take:
borg upgrade --tam <repository>
on every client for each repository.Prior versions can access and modify repositories with this measure enabled, however, to 1.0.9 or later their modifications are indiscernible from an attack and will raise an error until the below procedure is followed. We are aware that this can be be annoying in some circumstances, but don’t see a way to fix the vulnerability otherwise.
In case a version prior to 1.0.9 is used to modify a repository where above procedure was completed, and now you get an error message from other clients:
borg upgrade --tam --force <repository>
once with any client suffices.This attack is mitigated by:
borg list
, borg info
, or borg create --stats
, which
contain the archive IDs.We are not aware of others having discovered, disclosed or exploited this vulnerability.
Vulnerability time line:
If you have archives in your repository that were made with attic <= 0.13 (and later migrated to borg), running borg check would report errors in these archives. See issue #1837.
The reason for this is a invalid (and useless) metadata key that was always added due to a bug in these old attic versions.
If you run borg check –repair, things escalate quickly: all archive items with invalid metadata will be killed. Due to that attic bug, that means all items in all archives made with these old attic versions.
Some external errors (like network or disk I/O errors) could lead to corruption of the backup repository due to issue #1138.
A sign that this happened is if “E” status was reported for a file that can not be explained by problems with the source file. If you still have logs from “borg create -v –list”, you can check for “E” status.
Here is what could cause corruption and what you can do now:
This could lead to corrupted segment files.
Fix:
# check for corrupt chunks / segments:
borg check -v --repository-only REPO
# repair the repo:
borg check -v --repository-only --repair REPO
# make sure everything is fixed:
borg check -v --repository-only REPO
This could lead to archive metadata corruption.
Fix:
# check for corrupt archives:
borg check -v --archives-only REPO
# delete the corrupt archives:
borg delete --force REPO::CORRUPT_ARCHIVE
# make sure everything is fixed:
borg check -v --archives-only REPO
The best check that everything is ok is to run a dry-run extraction:
borg extract -v --dry-run REPO::ARCHIVE
Compatibility notes:
Fixes:
New features:
Other changes:
Fixes:
Other changes:
Compatibility notes:
New features:
Fixes:
Other changes:
New features:
Fixes:
Other changes:
Compatibility notes:
New features:
Fixes:
Other changes:
Compatibility notes:
New features:
Fixes:
Other changes:
Compatibility notes:
Running “borg init” via a “borg serve –append-only” server will not create an append-only repository anymore. Use “borg init –append-only” to initialize an append-only repository.
Repositories in the “repokey” and “repokey-blake2” modes with an empty passphrase are now treated as unencrypted repositories for security checks (e.g. BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK).
Previously there would be no prompts nor messages if an unknown repository in one of these modes with an empty passphrase was encountered. This would allow an attacker to swap a repository, if one assumed that the lack of password prompts was due to a set BORG_PASSPHRASE.
Since the “trick” does not work if BORG_PASSPHRASE is set, this does generally not affect scripts.
Repositories in the “authenticated” mode are now treated as the unencrypted repositories they are.
The client-side temporary repository cache now holds unencrypted data for better speed.
borg init: removed the short form of –append-only (-a).
borg upgrade: removed the short form of –inplace (-i).
New features:
Fixes:
Other changes:
Compatibility notes:
Fixes:
Other changes:
These belong to 1.1.0b4 release, but did not make it into changelog by then:
Compatibility notes:
New features:
Fixes:
check --verify-data
and others
instead of reporting integrity error, #2224 #2221Other changes:
Bug fixes:
New features:
“key export” can now generate a printable HTML page with both a QR code and
a human-readable “paperkey” representation (and custom text) through the
--qr-html
option.
The same functionality is also available through paperkey.html,
which is the same HTML page generated by --qr-html
. It works with existing
“key export” files and key files.
Other changes:
Compatibility notes:
Bug fixes:
New features:
Other changes:
Bug fixes:
Other changes:
Security fixes:
A flaw in the cryptographic authentication scheme in Borg allowed an attacker to spoof the manifest. See Pre-1.0.9 manifest spoofing vulnerability (CVE-2016-10099) above for the steps you should take.
CVE-2016-10099 was assigned to this vulnerability.
borg check: When rebuilding the manifest (which should only be needed very rarely) duplicate archive names would be handled on a “first come first serve” basis, allowing an attacker to apparently replace archives.
CVE-2016-10100 was assigned to this vulnerability.
Bug fixes:
Other changes:
Bug fixes:
New features:
Other changes:
Bug fixes:
New features:
Other changes:
New features:
Bug fixes:
Other changes:
Bug fixes:
New features:
Other changes:
avoid previous_location mismatch, #1741
due to the changed canonicalization for relative paths in PR #1711 / #1655 (implement /./ relpath hack), there would be a changed repo location warning and the user would be asked if this is ok. this would break automation and require manual intervention, which is unwanted.
thus, we automatically fix the previous_location config entry, if it only changed in the expected way, but still means the same location.
docs:
vagrant / tests:
Bug fixes:
New features:
add “borg key export” / “borg key import” commands, #1555, so users are able to backup / restore their encryption keys more easily.
Supported formats are the keyfile format used by borg internally and a special “paper” format with by line checksums for printed backups. For the paper format, the import is an interactive process which checks each line as soon as it is input.
add “borg debug-refcount-obj” to determine a repo objects’ referrer counts, #1352
Other changes:
Security fixes:
borg serve: fix security issue with remote repository access, #1428 If you used e.g. –restrict-to-path /path/client1/ (with or without trailing slash does not make a difference), it acted like a path prefix match using /path/client1 (note the missing trailing slash) - the code then also allowed working in e.g. /path/client13 or /path/client1000.
As this could accidentally lead to major security/privacy issues depending on the paths you use, the behaviour was changed to be a strict directory match. That means –restrict-to-path /path/client1 (with or without trailing slash does not make a difference) now uses /path/client1/ internally (note the trailing slash here!) for matching and allows precisely that path AND any path below it. So, /path/client1 is allowed, /path/client1/repo1 is allowed, but not /path/client13 or /path/client1000.
If you willingly used the undocumented (dangerous) previous behaviour, you may need to rearrange your –restrict-to-path paths now. We are sorry if that causes work for you, but we did not want a potentially dangerous behaviour in the software (not even using a for-backwards-compat option).
Bug fixes:
New features:
Other changes:
Bug fixes:
do not write objects to repository that are bigger than the allowed size, borg will reject reading them, #1451.
Important: if you created archives with many millions of files or directories, please verify if you can open them successfully, e.g. try a “borg list REPO::ARCHIVE”.
lz4 compression: dynamically enlarge the (de)compression buffer, the static buffer was not big enough for archives with extremely many items, #1453
larger item metadata stream chunks, raise archive item limit by 8x, #1452
fix untracked segments made by moved DELETEs, #1442
Impact: Previously (metadata) segments could become untracked when deleting data, these would never be cleaned up.
extended attributes (xattrs) related fixes:
Other changes:
Bug fixes:
New features:
Other changes:
Bug fixes:
Other changes:
New features:
Bug fixes:
Other changes:
Notes:
(*) Some features depend on information (chunks_healthy list) added to item metadata when a file with missing chunks was “repaired” using all-zero replacement chunks. The chunks_healthy list is generated since borg 1.0.4, thus borg can’t recognize such “repaired” (but content-damaged) files if the repair was done with an older borg version.
Bug fixes:
Other changes:
New features:
Bug fixes:
Other changes:
Bug fixes:
Other changes:
Bug fixes:
fix malfunction and potential corruption on (nowadays rather rare) big-endian architectures or bi-endian archs in (rare) BE mode. #886, #889
cache resync / index merge was malfunctioning due to this, potentially leading to data loss. borg info had cosmetic issues (displayed wrong values).
note: all (widespread) little-endian archs (like x86/x64) or bi-endian archs in (widespread) LE mode (like ARMEL, MIPSEL, …) were NOT affected.
add overflow and range checks for 1st (special) uint32 of the hashindex values, switch from int32 to uint32.
fix so that refcount will never overflow, but just stick to max. value after a overflow would have occurred.
borg delete: fix –cache-only for broken caches, #874
Makes –cache-only idempotent: it won’t fail if the cache is already deleted.
fixed borg create –one-file-system erroneously traversing into other filesystems (if starting fs device number was 0), #873
workround a bug in Linux fadvise FADV_DONTNEED, #907
Other changes:
New features:
Usually there are no new features in a bugfix release, but these were added due to their high impact on security/safety/speed or because they are fixes also:
Bug fixes:
Other changes:
The major release number change (0.x -> 1.x) indicates bigger incompatible changes, please read the compatibility notes, adapt / test your scripts and check your backup logs.
Compatibility notes:
drop support for python 3.2 and 3.3, require 3.4 or 3.5, #221 #65 #490 note: we provide binaries that include python 3.5.1 and everything else needed. they are an option in case you are stuck with < 3.4 otherwise.
change encryption to be on by default (using “repokey” mode)
moved keyfile keys from ~/.borg/keys to ~/.config/borg/keys, you can either move them manually or run “borg upgrade <REPO>”
remove support for –encryption=passphrase, use borg migrate-to-repokey to switch to repokey mode, #97
remove deprecated –compression <number>, use –compression zlib,<number> instead in case of 0, you could also use –compression none
remove deprecated –hourly/daily/weekly/monthly/yearly use –keep-hourly/daily/weekly/monthly/yearly instead
remove deprecated –do-not-cross-mountpoints, use –one-file-system instead
disambiguate -p option, #563:
remove deprecated “borg verify”, use “borg extract –dry-run” instead
cleanup environment variable semantics, #355 the environment variables used to be “yes sayers” when set, this was conceptually generalized to “automatic answerers” and they just give their value as answer (as if you typed in that value when being asked). See the “usage” / “Environment Variables” section of the docs for details.
change the builtin default for –chunker-params, create 2MiB chunks, #343 –chunker-params new default: 19,23,21,4095 - old default: 10,23,16,4095
one of the biggest issues with borg < 1.0 (and also attic) was that it had a default target chunk size of 64kiB, thus it created a lot of chunks and thus also a huge chunk management overhead (high RAM and disk usage).
please note that the new default won’t change the chunks that you already have in your repository. the new big chunks do not deduplicate with the old small chunks, so expect your repo to grow at least by the size of every changed file and in the worst case (e.g. if your files cache was lost / is not used) by the size of every file (minus any compression you might use).
in case you want to immediately see a much lower resource usage (RAM / disk) for chunks management, it might be better to start with a new repo than continuing in the existing repo (with an existing repo, you’ld have to wait until all archives with small chunks got pruned to see a lower resource usage).
if you used the old –chunker-params default value (or if you did not use –chunker-params option at all) and you’ld like to continue using small chunks (and you accept the huge resource usage that comes with that), just explicitly use borg create –chunker-params=10,23,16,4095.
archive timestamps: the ‘time’ timestamp now refers to archive creation start time (was: end time), the new ‘time_end’ timestamp refers to archive creation end time. This might affect prune if your backups take rather long. if you give a timestamp via cli this is stored into ‘time’, therefore it now needs to mean archive creation start time.
New features:
Bug fixes:
Other changes:
New features:
Bug fixes:
Other changes:
New features:
Bug fixes:
Other changes:
Compatibility notes:
Bug fixes:
New features:
Other changes:
Compatibility notes:
Bug fixes:
New features:
Other changes:
New features:
Other changes:
Bug fixes:
Other changes:
Compatibility notes:
New features:
Bug fixes:
Other changes:
New features:
Bug fixes:
Other changes:
This is a minor update, just docs and new pyinstaller binaries.
Note: if you did a python-based installation, there is no need to upgrade.
New features:
Bug fixes:
char *
from temporary Python value (old code causes
a compile error on Mint 17.2)undefined symbol FPE_
… error on some platforms)Other changes:
Compatibility notes:
Deprecations:
New features:
Bug fixes:
Other changes:
Incompatible changes (compared to 0.23):
Deprecations:
New features:
Bug fixes:
Other changes:
I forgot to list some stuff already implemented in 0.23.0, here they are:
New features:
Other changes:
Incompatible changes (compared to attic, fork related):
Bug fixes:
New features:
Other changes:
Here you can see the full list of changes between each Attic release until Borg forked from Attic:
(bugfix release, released on X)
(bugfix release, released on May 16, 2015)
(bugfix release, released on Apr 15, 2015)
(feature release, released on Dec 17, 2014)
(feature release, released on Jun 29, 2014)
--exclude-caches
(#74)(feature release, released on April 7, 2014)
attic mount
now supports mounting an entire repository not only
individual archives (#59)attic serve --restrict-to-path X
(#51)--stats
option to attic delete
and attic prune
attic prune
used UTC instead of the local time zone
when determining which archives to keep.(feature release, released on March 7, 2014)
(bugfix release, released on Jan 30, 2014)
(feature release, released on Jan 23, 2014)
(feature release, released on Oct 3, 2013)
(feature release, released on Aug 5, 2013)
(bugfix release, released on July 19, 2013)
First public release on July 9, 2013