Update to borg 1.2.7+ and add automatic migration steps

[MartinX3]

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

Or add a warning on first Vorta startup preventing a borg check without following them.

[m3nu]

Our release cycle isn't fast enough to address this ad-hoc. And many users will not run 1.2.6 yet. So Vorta may not be the right place to address this. We only aim to cover the most frequent commands and not 100%.

[MartinX3]

But doesn't Vorta run periodic checks on the repo by default?
This could kill the backups if I read the warning correctly.

It's about 1.2.6 on the client and >=1.2.4 on the server.

And these steps need to be done with the 1.2.6 client.
Step 3 is impossible with 1.2.4.
(And 1.2.5 needs to be avoided because of a breaking bug)

[real-yfprojects]

Vorta doesnbt upgrade borg. Consequently the user is responsible with following the proper upgrade steps. However we do provide a flatpak and homebrew package with bundled borg. Upgrading borg in those needs special attention.

[MartinX3]

Oh, I am sorry.
I just saw 1.2.4 as the borg version in vorta so I thought it was bundled.
But all I need to do was to restart vorta.

[real-yfprojects]

Oh, I am sorry. I just saw 1.2.4 as the borg version in vorta so I thought it was bundled. But all I need to do was to restart vorta.

Yeah, the version is only checked on restart. Checking the version regularly while running wouldn't make much sense, would it.

[MartinX3]

Hmmm, maybe vorta should execute the tam-signature check first before the regular borg check and give us a warning dialog which steps we should do by ourselves and before it is done denying any more borg check.
Just to avoid data loss.
If the repo has no problems a flag could be set showing vorta that the repo is save and prevent any further tam-signature checks.

[real-yfprojects]

How should Vorta know that you updated your borg version? Running the check every time Vorta starts, doesn't seem viable to me.

[Hofer-Julian]

For the flatpak, I keep borg pinned to 1.24 at the moment: https://github.com/flathub/com.borgbase.Vorta/blob/a08e83a9da5c34c5040d59b9b316c16c007f72b8/dependencies/borgbackup.json#L10

I assume this is still the way to go until this (or a similar) feature is implemented?

[sten0]

This will affect a couple thousand users as soon as this April, when Ubuntu 22.04 is released with Borg 1.2.7, and it already affects Ubuntu 23.10 users. Yes, Debian testing or unstable users are also currently affected. It is not possible for affected users to downgrade Borg.

If "borg check" will cause data loss for some cases, then these cases should be handled so as not to cause data loss. Trust in backup software is like trust in a file system: people don't give second chances. It is better for backup software to say "sorry, you're using an unsupported version of borg" than to cause data loss. GUI users may need a borg repo upgrade wizard function to navigate this sort of issue.

[real-yfprojects]

@ThomasWaldmann Is there a way to determine the borg version that was last used to access a repo?
Or any other way of determining that the upgrade steps in question are needed?

[ThomasWaldmann]

• no (and also the situation is quite complicated, so knowing the version is not always good enough, except maybe if a repo was created with borg >= 1.2.6)
• guess one could use the steps listed in the cve / upgrade notes of borg to detect if there is are upgrade steps needed. For borg > 1.2.4 manifest and archives all must have a TAM (including .checkpoint archives for completeness).
• there could be also a convenience single-click "check and upgrade" action that trusts everything currently in the repo. that's not what paranoid / very cautious users want, but guess it is good enough for most users.

[m3nu]

I could add a "TAM Upgrade" button and command fairly quickly together with a link for more details. Or we only watch the logs for the relevant error and display an alert with a link for more details.

OTOH, the macOS release has included a newer Borg version since last year and I don't recall getting many questions. Also not to our support. We pointed the issue out twice in the monthly BorgBase newsletter. So it's possible this doesn't affect as many users? I believe I only had to upgrade one of my repos, which was missing the TAM for one archive only. So this case may be the most common?

If there are no tam:none archives left at this point, you can skip this step.

[ramcq]

I found this ticket as I use the Vorta Flatpak - I am intermittently encountering borgbackup/borg#6687 so I was looking if I could update the Flatpak to 1.2.7 which led me here. I think Vorta could potentially aid the migration by tracking, per archive, a boolean indicating whether the migration has been carried out - for existing archives where this flag is false, it could automatically check TAM validity and flip it to true, which seems to be a common case. If the TAM is not valid it can notify the user with a warning / link to the advisory and an explicit step to do the upgrade. Once an archive has been migrated, or if it was newly created, it should simply enforce that the TAM is valid and not offer the migration path - this would avoid Vorta ever allowing the migration to be carried out more than once and any TAM invalidity can then be reported with the appropriate severity to the user.

[hozza]

I've run into this issue after doing an initial backup (to borgbase) with flatpak Vorta (using bundled borg 1.2.4).

I get errors when attempting to setup automated regular backups using borgmatic-collective/docker-borgmatic docker container.

It turns out the docker-borgmatic container uses borg 1.2.7, thankfully I was using an append-only ssh key so helpfully no data loss from the check run (although I'm not sure on that?). I'll disable auto backups with this until Vorta implements a "fix/upgrade repo" option or updates the bundled borg I guess?

(I use Vorta manually with a privileged ssh key on a trusted device for repo prune/management, and an append only ssh key on the actual backup client device in case of it being compromised and attempting to destroy it's own backups for ransom or whatever.)

Is this something that Borgbase should alert users about on the dashboard/by email?

This self corrupting version issue feels a little like Captin Janeway realising a nanovirus into the central plexus of a class-4 tactical cube. 🦾

[ThomasWaldmann]

@hozza The steps you should do for your repo are described at the top of the borg 1.2.7 changelog. You could just copy&paste and slightly modify these for your repo URL.

https://borgbackup.readthedocs.io/en/1.2.7/changes.html

Guess nothing bad happens, if you don't run borg check --repair until then with borg > 1.2.4.

[ThomasWaldmann]

I had some time and added some helper commands to simplify the upgrade steps.

I would appreciate some review and practical testing of borgbackup/borg#8159 .

The new commands are for checking whether something needs to be done and exit with rc=0 if all looks OK and rc=1 if something TAM-related needs fixing.

Of course these new commands will only be available with borg >= 1.2.8.