Aggregator

btrfs-backup-ng-0.9.20-2.fc43

Fedora Security Advisories
3 days 7 hours ago
FEDORA-2026-28cd8623c6 Packages in this update:
  • btrfs-backup-ng-0.9.20-2.fc43
Update description:

Update to 0.9.20. This replaces the 0.9.19 update before it reached testing. It carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, three concurrency and accounting fixes from 0.9.19, and 0.9.20's fix for the shared-lock retry bound, which the previous Fedora build carried as a patch. 0.9.17 through 0.9.19 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant, including under heavy contention on a slow machine. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.20/CHANGELOG.md

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

notes=Update to 0.9.18, which carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph) and a fix for a regression in 0.9.17. 0.9.17 was not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

0.9.18 fixes the 0.9.17 regression where every exclusive lock on a local btrfs destination on kernel 6.6 or newer failed with "remote lock ... is busy", so a receive or prune into a local btrfs location could not run.

This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.18/CHANGELOG.md

Update to 0.9.16.

  • A source could keep a snapshot forever and send it again in full on every run; fixed on the first run after upgrading.
  • On a root-owned destination with ssh_sudo, locks went stale while a transfer was still running; the heartbeat now elevates like the acquire (expect one "sudo -n sh -c" per beat in the sudo log).
  • restore --unlock no longer erases a pin a running restore has just taken.
  • doctor reports who holds each pin, and --fix repairs only what it can prove is stale.

A .btrfs-backup-ng.locks.holders directory now appears beside each lock file; it is runtime state, and older versions ignore it.

This update includes all changes since 0.9.12.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.16/CHANGELOG.md

Update to 0.9.15.

  • Pins on the source could be lost or left behind when several targets sent in parallel; fixed.
  • A compressed ssh:// backup to a remote without the decompressor is refused before the transfer starts, instead of failing after the stream has been sent.
  • estimate exits 2 when it could not measure and 3 when the destination is short of space (it exited 0), and can now measure an ssh:// source.
  • Pins on the source could be lost or left behind when several targets sent in parallel; fixed. Backups on the targets were not affected

This update includes all changes since 0.9.12, including 0.9.13's fixes for systems without sudo, openssl or bash as sh.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.15/CHANGELOG.md

Update to 0.9.14.

Fixes the test suite failing at startup with pytest older than 8.4 (upstream #121). There are no changes to the program itself. 0.9.14 also includes all of 0.9.13's fixes.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.14/CHANGELOG.md

Update to 0.9.13.

This release fixes failures on systems without the usual privileges or tools:

  • A compressed backup to an ssh:// target whose remote sh is dash 0.5.13.0-0.5.13.4 failed. Nothing was written, and existing backups are not affected.
  • A machine without sudo failed with "No such file or directory: 'sudo'". It now says what is needed; run stops at startup and doctor reports it.
  • Size estimates failed when sudo refused or was missing, although the snapshot was readable. du is now retried as the user.
  • A restore without openssl reported a missing passphrase instead of the missing program.

Changes you may notice after upgrading:

  • config validate and doctor now check the snapper configuration and snapshot_dir that run depends on, so they can report an error for a configuration they accepted before.
  • A space check based on a du figure (an upper bound) warns and proceeds instead of refusing.
  • A sudo password containing a line break is refused with a message saying why.
  • doctor has a new local_privilege check.

Packaging: the package now requires lzop (the program used for lzo compression) instead of the lzo library, and the build runs the full test suite, including the compression tests.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.13/CHANGELOG.md

Update to 0.9.12

btrfs-backup-ng-0.9.20-1.fc44

Fedora Security Advisories
3 days 7 hours ago
FEDORA-2026-d5ef07277c Packages in this update:
  • btrfs-backup-ng-0.9.20-1.fc44
Update description:

Update to 0.9.20. This replaces the 0.9.19 update before it reached testing. It carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, three concurrency and accounting fixes from 0.9.19, and 0.9.20's fix for the shared-lock retry bound, which the previous Fedora build carried as a patch. 0.9.17 through 0.9.19 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant, including under heavy contention on a slow machine. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.20/CHANGELOG.md

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

notes=Update to 0.9.18, which carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph) and a fix for a regression in 0.9.17. 0.9.17 was not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

0.9.18 fixes the 0.9.17 regression where every exclusive lock on a local btrfs destination on kernel 6.6 or newer failed with "remote lock ... is busy", so a receive or prune into a local btrfs location could not run.

This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.18/CHANGELOG.md

btrfs-backup-ng-0.9.20-1.fc45

Fedora Security Advisories
3 days 7 hours ago
FEDORA-2026-a44f471fef Packages in this update:
  • btrfs-backup-ng-0.9.20-1.fc45
Update description:

Update to 0.9.20. This replaces the 0.9.19 update before it reached testing. It carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, three concurrency and accounting fixes from 0.9.19, and 0.9.20's fix for the shared-lock retry bound, which the previous Fedora build carried as a patch. 0.9.17 through 0.9.19 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant, including under heavy contention on a slow machine. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.20/CHANGELOG.md

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

btrfs-backup-ng-0.9.19-2.fc45

Fedora Security Advisories
3 days 10 hours ago
FEDORA-2026-a3476b0ca9 Packages in this update:
  • btrfs-backup-ng-0.9.19-2.fc45
Update description:

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

btrfs-backup-ng-0.9.19-2.fc44

Fedora Security Advisories
3 days 10 hours ago
FEDORA-2026-c63010d328 Packages in this update:
  • btrfs-backup-ng-0.9.19-2.fc44
Update description:

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

notes=Update to 0.9.18, which carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph) and a fix for a regression in 0.9.17. 0.9.17 was not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

0.9.18 fixes the 0.9.17 regression where every exclusive lock on a local btrfs destination on kernel 6.6 or newer failed with "remote lock ... is busy", so a receive or prune into a local btrfs location could not run.

This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.18/CHANGELOG.md

btrfs-backup-ng-0.9.19-3.fc43

Fedora Security Advisories
3 days 10 hours ago
FEDORA-2026-7849dfa12e Packages in this update:
  • btrfs-backup-ng-0.9.19-3.fc43
Update description:

Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

Also fixed since 0.9.16: - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning. - A shared snapshot pin no longer fails with "could not lock ... refusing to continue" when another holder releases at the same instant; the acquire retries like the exclusive one does. - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

No configuration or on-disk format changes. This update includes all changes since 0.9.16.

Carries a patch raising the shared-lock retry bound, sent upstream.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

notes=Update to 0.9.18, which carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph) and a fix for a regression in 0.9.17. 0.9.17 was not shipped to this release.

Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read. Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened; stores created by a root timer or over ssh are 0755 and unaffected. New stores are created 0755 regardless of umask.

0.9.18 fixes the 0.9.17 regression where every exclusive lock on a local btrfs destination on kernel 6.6 or newer failed with "remote lock ... is busy", so a receive or prune into a local btrfs location could not run.

This update includes all changes since 0.9.16.

Advisory: https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.18/CHANGELOG.md

Update to 0.9.16.

  • A source could keep a snapshot forever and send it again in full on every run; fixed on the first run after upgrading.
  • On a root-owned destination with ssh_sudo, locks went stale while a transfer was still running; the heartbeat now elevates like the acquire (expect one "sudo -n sh -c" per beat in the sudo log).
  • restore --unlock no longer erases a pin a running restore has just taken.
  • doctor reports who holds each pin, and --fix repairs only what it can prove is stale.

A .btrfs-backup-ng.locks.holders directory now appears beside each lock file; it is runtime state, and older versions ignore it.

This update includes all changes since 0.9.12.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.16/CHANGELOG.md

Update to 0.9.15.

  • Pins on the source could be lost or left behind when several targets sent in parallel; fixed.
  • A compressed ssh:// backup to a remote without the decompressor is refused before the transfer starts, instead of failing after the stream has been sent.
  • estimate exits 2 when it could not measure and 3 when the destination is short of space (it exited 0), and can now measure an ssh:// source.
  • Pins on the source could be lost or left behind when several targets sent in parallel; fixed. Backups on the targets were not affected

This update includes all changes since 0.9.12, including 0.9.13's fixes for systems without sudo, openssl or bash as sh.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.15/CHANGELOG.md

Update to 0.9.14.

Fixes the test suite failing at startup with pytest older than 8.4 (upstream #121). There are no changes to the program itself. 0.9.14 also includes all of 0.9.13's fixes.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.14/CHANGELOG.md

Update to 0.9.13.

This release fixes failures on systems without the usual privileges or tools:

  • A compressed backup to an ssh:// target whose remote sh is dash 0.5.13.0-0.5.13.4 failed. Nothing was written, and existing backups are not affected.
  • A machine without sudo failed with "No such file or directory: 'sudo'". It now says what is needed; run stops at startup and doctor reports it.
  • Size estimates failed when sudo refused or was missing, although the snapshot was readable. du is now retried as the user.
  • A restore without openssl reported a missing passphrase instead of the missing program.

Changes you may notice after upgrading:

  • config validate and doctor now check the snapper configuration and snapshot_dir that run depends on, so they can report an error for a configuration they accepted before.
  • A space check based on a du figure (an upper bound) warns and proceeds instead of refusing.
  • A sudo password containing a line break is refused with a message saying why.
  • doctor has a new local_privilege check.

Packaging: the package now requires lzop (the program used for lzo compression) instead of the lzo library, and the build runs the full test suite, including the compression tests.

Full changelog: https://github.com/berrym/btrfs-backup-ng/blob/v0.9.13/CHANGELOG.md

Update to 0.9.12