Release 1.2.6

[ThomasWaldmann]

borgbackup 1.2.6 release

This release includes a security fix plus a fixed upgrade procedure at the top of the change log:

https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811

Long changelog:

https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#version-126-2023-08-31

Short borg 1.2 overview (from a borg 1.1 perspective):

https://www.borgbackup.org/releases/borg-1.2.html

Installation

If you use pip to install this, use: pip install pkgconfig ; pip install "borgbackup==1.2.6"

For other installation methods and more details, please see: https://borgbackup.org/

---

This discussion was created from the release Release 1.2.6.

[PhrozenByte]

Thanks for the new release ❤️

Following the upgrade instructions one should (must?) not run borg check before borg upgrade. However, it's not made clear what happens if one doesn't run borg upgrade. What might happen? Both for just borg check, as well as borg check --repair. Are other commands affected as well? Both in the short-term, and possibly in the long-term? What happens if one runs borg upgrade, but then proceeds using an old Borg < 1.2.5 client with the repo?

[utaxiu]

Yeah, you are on point.

Borg's documentation about borg check says this:

The check command is a readonly task by default. If any corruption is found, Borg will report the issue and proceed with checking.

And about borg check --repair:

Repair mode will attempt to fix any corruptions found. Fixing corruptions does not mean recovering lost data: Borg can not magically restore data lost due to e.g. a hardware failure. Repairing a repository means sacrificing some data for the sake of the repository as a whole and the remaining data. Hence it is, by definition, a potentially lossy task. In practice, repair mode hooks into both the repository and archive checks:

When checking the repository’s consistency, repair mode will try to recover as many objects from segments with integrity errors as possible, and ensure that the index is consistent with the data stored in the segments.

When checking the consistency and correctness of archives, repair mode might remove whole archives from the manifest if their archive metadata chunk is corrupt or lost. On a chunk level (i.e. the contents of files), repair mode will replace corrupt or lost chunks with a same-size replacement chunk of zeroes. If a previously zeroed chunk reappears, repair mode will restore this lost chunk using the new chunk. Lastly, repair mode will also delete orphaned chunks (e.g. caused by read errors while creating the archive).

So I assume that running borg check without --repair argument is safe for the data and should only produce errors (it is a integrity violation so warning shouldn't be enough).

It would be nice to test this behaviour but I don't have a knowledge to make 'tam:none' archive in repository.

Have a nice day.

[ThomasWaldmann]

borg check --repair would just remove TAM-less or invalid-TAM archives:

1. archives that resulted from a borg rename or borg recreate operation (that is due to a bug in borg < 1.2.5 and maybe the most serious scenario to lose recent backups)
2. archives from borg < 1.0.9 (older borg did not know about TAMs, so one could lose such backup archives)
3. archives from attacks
4. other invalid / corrupted archives

1. and 2. can be fixed by following the upgrade procedure before running borg check --repair.

Maybe logging needs improvements still, I'll file an issue about that.

[FabioPedretti]

Thank you for considering to the security aspect of the project. Do you plan to release an updated 1.1 release, or is it to be considered in End of Life by now? Thanks.

[ThomasWaldmann]

1.1.x is EOL, so there won't be a release from me.

If anybody wants to backport changes to 1.1-maint branch, I would accept/review such PRs.

[ThomasWaldmann]

https://github.com/borgbackup/borg/pull/7798/files improved logging for borg check (for next release after 1.2.6).