Update webpki-roots / webpki-root-certs to version 1.0.11. These releases contain a followup fix for the eMudhra Intermediate CA Compromise.
Update to expat-2.9.0.
Update to expat-2.8.5.
Update to expat-2.9.0.
Update to expat-2.8.5.
Automatic update for openscap-1.4.6-1.fc46.
Changelog * Fri Oct 23 2026 Jan Černý <jcerny@redhat.com> - 1:1.4.6-1 - Upgrade to the latest upstream release - CVE-2026-85518: Fix path traversal when dumping SDS components (RHBZ#2558499)Update pcre2 to 10.49, fixing security issues (CVE-2026-86145, CVE-2026-89156, CVE-2026-89157, CVE-2026-89158, CVE-2026-89160, CVE-2026-89161, CVE-2026-89162, CVE-2026-103111)
Release notes: https://github.com/PCRE2Project/pcre2/releases/tag/pcre2-10.49 https://github.com/PCRE2Project/pcre2/releases#release-pcre2-10.48
ABI changes were checked between 10.47 and 10.49 and were not found to be significant, the updates are primarily focused on fixing security vulnerabilities.
Update pcre2 to 10.49, fixing security issues (CVE-2026-86145, CVE-2026-89156, CVE-2026-89157, CVE-2026-89158, CVE-2026-89160, CVE-2026-89161, CVE-2026-89162, CVE-2026-103111)
Release notes: https://github.com/PCRE2Project/pcre2/releases/tag/pcre2-10.49 https://github.com/PCRE2Project/pcre2/releases#release-pcre2-10.48
ABI changes were checked between 10.47 and 10.49 and were not found to be significant, the updates are primarily focused on fixing security vulnerabilities.
Rebuilt with updated rustls and webpki dependencies, including updated CA certificates for the eMudhra intermediate CA compromise.
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
Update to 156.0.8078.47, include 353 security fixes: CVE-2026-112992 - CVE-2026-113344
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 .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.
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:
Changes you may notice after upgrading:
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
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.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
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
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.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 .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.
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:
Changes you may notice after upgrading:
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