borgbackup 1.4.0b1__tar.gz → 1.4.0b2__tar.gz

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/Brewfile

@@ -2,7 +2,7 @@ brew 'pkg-config'
 brew 'zstd'
 brew 'lz4'
 brew 'xxhash'
-brew 'openssl@1.1'
+brew 'openssl@3.0'
 
 # osxfuse (aka macFUSE) is only required for "borg mount",
 # but won't work on github actions' workers.

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/CHANGES.rst

@@ -29,49 +29,63 @@ places. Borg now considers archives without TAM as garbage or an attack.
 
 We are not aware of others having discovered, disclosed or exploited this vulnerability.
 
-Below, if we speak of borg 1.2.6, we mean a borg version >= 1.2.6 **or** a
-borg version that has the relevant security patches for this vulnerability applied
+Below, if we speak of borg 1.2.8, we mean a borg version >= 1.2.8 **or** a
+borg version that has the relevant patches for this vulnerability applied
 (could be also an older version in that case).
 
 Steps you must take to upgrade a repository (this applies to all kinds of repos
 no matter what encryption mode they use, including "none"):
 
-1. Upgrade all clients using this repository to borg 1.2.6.
+1. Upgrade all clients using this repository to borg 1.2.8.
    Note: it is not required to upgrade a server, except if the server-side borg
    is also used as a client (and not just for "borg serve").
 
-   Do **not** run ``borg check`` with borg 1.2.6 before completing the upgrade steps:
+   Do **not** run ``borg check`` with borg > 1.2.4 before completing the upgrade steps:
 
    - ``borg check`` would complain about archives without a valid archive TAM.
    - ``borg check --repair`` would remove such archives!
-2. Run: ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug <repo> 2>&1 | grep TAM | grep -i manifest``
+2. Do this step on every client using this repo: ``borg upgrade --show-rc --check-tam <repo>``
 
-   a) If you get "TAM-verified manifest", continue with 3.
-   b) If you get "Manifest TAM not found and not required", run
-      ``borg upgrade --tam --force <repository>`` *on every client*.
+   This will check the manifest TAM authentication setup in the repo and on this client.
+   The command will exit with rc=0 if all is OK, otherwise with rc=1.
 
-3. Run: ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg list --consider-checkpoints --format='{name} {time} tam:{tam}{NL}' <repo>``
+   a) If you get "Manifest authentication setup OK for this client and this repository."
+      and rc=0, continue with 3.
+   b) If you get some warnings and rc=1, run:
+      ``borg upgrade --tam --force <repository>``
 
-   "tam:verified" means that the archive has a valid TAM authentication.
-   "tam:none" is expected as output for archives created by borg <1.0.9.
-   "tam:none" is also expected for archives resulting from a borg rename
-   or borg recreate operation (see #7791).
-   "tam:none" could also come from archives created by an attacker.
-   You should verify that "tam:none" archives are authentic and not malicious
+3. Run: ``borg upgrade --show-rc --check-archives-tam <repo>``
+
+   This will create a report about the TAM status for all archives.
+   In the last line(s) of the report, it will also report the overall status.
+   The command will exit with rc=0 if all archives are TAM authenticated or with rc=1
+   if there are some archives with TAM issues.
+
+   If there are no issues and all archives are TAM authenticated, continue with 5.
+
+   Archive TAM issues are expected for:
+
+   - archives created by borg <1.0.9.
+   - archives resulting from a borg rename or borg recreate operation (see #7791)
+
+   But, important, archive TAM issues could also come from archives created by an attacker.
+   You should verify that archives with TAM issues are authentic and not malicious
    (== have good content, have correct timestamp, can be extracted successfully).
    In case you find crappy/malicious archives, you must delete them before proceeding.
+
    In low-risk, trusted environments, you may decide on your own risk to skip step 3
    and just trust in everything being OK.
 
-4. If there are no tam:none archives left at this point, you can skip this step.
-   Run ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg upgrade --archives-tam <repo>``.
+4. If there are no archives with TAM issues left at this point, you can skip this step.
+
+   Run ``borg upgrade --archives-tam <repo>``.
+
    This will unconditionally add a correct archive TAM to all archives not having one.
    ``borg check`` would consider TAM-less or invalid-TAM archives as garbage or a potential attack.
-   To see that all archives now are "tam:verified" run: ``borg list --consider-checkpoints --format='{name} {time} tam:{tam}{NL}' <repo>``
 
-5. Please note that you should never use BORG_WORKAROUNDS=ignore_invalid_archive_tam
-   for normal production operations - it is only needed once to get the archives in a
-   repository into a good state. All archives have a valid TAM now.
+   To see that all archives are OK now, you can optionally repeat the command from step 3.
+
+5. Done. Manifest and archives are TAM authenticated now.
 
 Vulnerability time line:
 
@@ -305,10 +319,13 @@ Compatibility notes:
 By default, borg 1.4 will behave quite similar to borg 1.2 (it was forked off
 from 1.2-maint branch at 1.2.7).
 
-For better error handling in your scripts, wrappers or GUI frontends, you may
-want to use BORG_EXIT_CODES=modern - in that case you of course will need to
-make sure these deal with the new error and warning exit codes, see
-internals/frontends docs.
+- the slashdot hack: be careful not to accidentally give paths containing /./
+  to "borg create" if you do not want to trigger this feature (which strips the
+  left part of the path from archived items).
+- BORG_EXIT_CODES=modern is a feature that borg script, wrapper and GUI authors
+  may want to use to get more specific error and warning return codes from borg.
+  In that case, of course they will need to make sure to correctly deal with these
+  new codes, see the internals/frontends docs.
 
 borg 1.1.x to 1.2.x
 -------------------
@@ -394,7 +411,8 @@ Compatibility notes:
 Change Log
 ==========
 
-Version 1.4.0b1 (2024-01-21)
+
+Version 1.4.0b2 (2024-03-31)
 ----------------------------
 
 For upgrade and compatibility hints, please also read the section "Upgrade Notes"
@@ -402,6 +420,51 @@ above.
 
 Fixes:
 
+- check: fix return code for index entry value discrepancies
+- benchmark: inherit options --rsh --remote-path, #8099
+- sdist: dynamically compute readme (long_description)
+- create: deal with EBUSY, #8123
+- No need to use OpenSSL 3.0 on OpenBSD, use LibreSSL.
+- fix Ctrl-C / SIGINT behaviour for pyinstaller-made binaries, #8155
+
+New features:
+
+- create: add the slashdot hack, update docs, #4685
+- upgrade --check-tam: check manifest TAM auth, exit with rc=1 if there are issues.
+- upgrade --check-archives-tam: check archives TAM auth, exit with rc=1 if there are issues.
+
+Other changes:
+
+- improve acl_get / acl_set error handling, improved/added tests, #8125
+- remove bundled lz4/zstd/xxhash code (require the respective libs/headers),
+  simplify setup.py, remove support for all BORG_USE_BUNDLED_*=YES, #8094
+- require Cython 3.0.3 at least (fixes py312 memory leak), #8133
+- allow msgpack 1.0.8, #8133
+- init: better borg key export instructions
+- init: remove compatibility warning for borg <=1.0.8
+  The warning refers to a compatibility issue not relevant any
+  more since borg 1.0.9 (released 2016-12).
+- locate libacl via pkgconfig
+- scripts/make.py: move clean, build_man, build_usage to there,
+  so we do not need to invoke setup.py directly, update docs
+- docs:
+
+  - how to run the testsuite using the dist package
+  - add non-root deployment strategy (systemd / capabilities)
+  - simplify TAM-related upgrade docs using the new commands
+- vagrant:
+
+  - use python 3.11.8
+  - use pyinstaller 6.5.0
+  - add xxhash for macOS, add libxxhash-dev for debianoid systems
+  - use openindiana/hipster box
+
+
+Version 1.4.0b1 (2024-01-21)
+----------------------------
+
+Fixes:
+
 - fix CommandError args, #8029
 
 New features:

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: borgbackup
-Version: 1.4.0b1
+Version: 1.4.0b2
 Summary: Deduplicated, encrypted, authenticated and compressed backups
 Author: The Borg Collective (see AUTHORS file)
 Maintainer-email: Thomas Waldmann <tw@waldmann-edv.de>
@@ -29,10 +29,9 @@ Classifier: Programming Language :: Python :: 3.12
 Classifier: Topic :: Security :: Cryptography
 Classifier: Topic :: System :: Archiving :: Backup
 Requires-Python: >=3.9
-Description-Content-Type: text/x-rst
 License-File: LICENSE
 License-File: AUTHORS
-Requires-Dist: msgpack<=1.0.7,>=1.0.3
+Requires-Dist: msgpack<=1.0.8,>=1.0.3
 Requires-Dist: packaging
 Provides-Extra: llfuse
 Requires-Dist: llfuse>=1.3.8; extra == "llfuse"
@@ -40,9 +39,6 @@ Provides-Extra: pyfuse3
 Requires-Dist: pyfuse3>=3.1.1; extra == "pyfuse3"
 Provides-Extra: nofuse
 
-|screencast_basic|
-
-More screencasts: `installation`_, `advanced usage`_
 
 What is BorgBackup?
 -------------------
@@ -211,33 +207,4 @@ THIS IS SOFTWARE IN DEVELOPMENT, DECIDE YOURSELF WHETHER IT FITS YOUR NEEDS.
 Security issues should be reported to the `Security contact`_ (or
 see ``docs/support.rst`` in the source distribution).
 
-.. start-badges
-
-|doc| |build| |coverage| |bestpractices|
-
-.. |doc| image:: https://readthedocs.org/projects/borgbackup/badge/?version=stable
-        :alt: Documentation
-        :target: https://borgbackup.readthedocs.org/en/stable/
-
-.. |build| image:: https://github.com/borgbackup/borg/workflows/CI/badge.svg?branch=master
-        :alt: Build Status (master)
-        :target: https://github.com/borgbackup/borg/actions
-
-.. |coverage| image:: https://codecov.io/github/borgbackup/borg/coverage.svg?branch=master
-        :alt: Test Coverage
-        :target: https://codecov.io/github/borgbackup/borg?branch=master
-
-.. |screencast_basic| image:: https://asciinema.org/a/133292.png
-        :alt: BorgBackup Basic Usage
-        :target: https://asciinema.org/a/133292?autoplay=1&speed=1
-        :width: 100%
-
-.. _installation: https://asciinema.org/a/133291?autoplay=1&speed=1
-
-.. _advanced usage: https://asciinema.org/a/133293?autoplay=1&speed=1
-
-.. |bestpractices| image:: https://bestpractices.coreinfrastructure.org/projects/271/badge
-        :alt: Best Practices Score
-        :target: https://bestpractices.coreinfrastructure.org/projects/271
 
-.. end-badges

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/changes.rst

@@ -29,49 +29,63 @@ places. Borg now considers archives without TAM as garbage or an attack.
 
 We are not aware of others having discovered, disclosed or exploited this vulnerability.
 
-Below, if we speak of borg 1.2.6, we mean a borg version >= 1.2.6 **or** a
-borg version that has the relevant security patches for this vulnerability applied
+Below, if we speak of borg 1.2.8, we mean a borg version >= 1.2.8 **or** a
+borg version that has the relevant patches for this vulnerability applied
 (could be also an older version in that case).
 
 Steps you must take to upgrade a repository (this applies to all kinds of repos
 no matter what encryption mode they use, including "none"):
 
-1. Upgrade all clients using this repository to borg 1.2.6.
+1. Upgrade all clients using this repository to borg 1.2.8.
    Note: it is not required to upgrade a server, except if the server-side borg
    is also used as a client (and not just for "borg serve").
 
-   Do **not** run ``borg check`` with borg 1.2.6 before completing the upgrade steps:
+   Do **not** run ``borg check`` with borg > 1.2.4 before completing the upgrade steps:
 
    - ``borg check`` would complain about archives without a valid archive TAM.
    - ``borg check --repair`` would remove such archives!
-2. Run: ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug <repo> 2>&1 | grep TAM | grep -i manifest``
+2. Do this step on every client using this repo: ``borg upgrade --show-rc --check-tam <repo>``
 
-   a) If you get "TAM-verified manifest", continue with 3.
-   b) If you get "Manifest TAM not found and not required", run
-      ``borg upgrade --tam --force <repository>`` *on every client*.
+   This will check the manifest TAM authentication setup in the repo and on this client.
+   The command will exit with rc=0 if all is OK, otherwise with rc=1.
 
-3. Run: ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg list --consider-checkpoints --format='{name} {time} tam:{tam}{NL}' <repo>``
+   a) If you get "Manifest authentication setup OK for this client and this repository."
+      and rc=0, continue with 3.
+   b) If you get some warnings and rc=1, run:
+      ``borg upgrade --tam --force <repository>``
 
-   "tam:verified" means that the archive has a valid TAM authentication.
-   "tam:none" is expected as output for archives created by borg <1.0.9.
-   "tam:none" is also expected for archives resulting from a borg rename
-   or borg recreate operation (see #7791).
-   "tam:none" could also come from archives created by an attacker.
-   You should verify that "tam:none" archives are authentic and not malicious
+3. Run: ``borg upgrade --show-rc --check-archives-tam <repo>``
+
+   This will create a report about the TAM status for all archives.
+   In the last line(s) of the report, it will also report the overall status.
+   The command will exit with rc=0 if all archives are TAM authenticated or with rc=1
+   if there are some archives with TAM issues.
+
+   If there are no issues and all archives are TAM authenticated, continue with 5.
+
+   Archive TAM issues are expected for:
+
+   - archives created by borg <1.0.9.
+   - archives resulting from a borg rename or borg recreate operation (see #7791)
+
+   But, important, archive TAM issues could also come from archives created by an attacker.
+   You should verify that archives with TAM issues are authentic and not malicious
    (== have good content, have correct timestamp, can be extracted successfully).
    In case you find crappy/malicious archives, you must delete them before proceeding.
+
    In low-risk, trusted environments, you may decide on your own risk to skip step 3
    and just trust in everything being OK.
 
-4. If there are no tam:none archives left at this point, you can skip this step.
-   Run ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg upgrade --archives-tam <repo>``.
+4. If there are no archives with TAM issues left at this point, you can skip this step.
+
+   Run ``borg upgrade --archives-tam <repo>``.
+
    This will unconditionally add a correct archive TAM to all archives not having one.
    ``borg check`` would consider TAM-less or invalid-TAM archives as garbage or a potential attack.
-   To see that all archives now are "tam:verified" run: ``borg list --consider-checkpoints --format='{name} {time} tam:{tam}{NL}' <repo>``
 
-5. Please note that you should never use BORG_WORKAROUNDS=ignore_invalid_archive_tam
-   for normal production operations - it is only needed once to get the archives in a
-   repository into a good state. All archives have a valid TAM now.
+   To see that all archives are OK now, you can optionally repeat the command from step 3.
+
+5. Done. Manifest and archives are TAM authenticated now.
 
 Vulnerability time line:
 
@@ -305,10 +319,13 @@ Compatibility notes:
 By default, borg 1.4 will behave quite similar to borg 1.2 (it was forked off
 from 1.2-maint branch at 1.2.7).
 
-For better error handling in your scripts, wrappers or GUI frontends, you may
-want to use BORG_EXIT_CODES=modern - in that case you of course will need to
-make sure these deal with the new error and warning exit codes, see
-internals/frontends docs.
+- the slashdot hack: be careful not to accidentally give paths containing /./
+  to "borg create" if you do not want to trigger this feature (which strips the
+  left part of the path from archived items).
+- BORG_EXIT_CODES=modern is a feature that borg script, wrapper and GUI authors
+  may want to use to get more specific error and warning return codes from borg.
+  In that case, of course they will need to make sure to correctly deal with these
+  new codes, see the internals/frontends docs.
 
 borg 1.1.x to 1.2.x
 -------------------
@@ -394,7 +411,8 @@ Compatibility notes:
 Change Log
 ==========
 
-Version 1.4.0b1 (2024-01-21)
+
+Version 1.4.0b2 (2024-03-31)
 ----------------------------
 
 For upgrade and compatibility hints, please also read the section "Upgrade Notes"
@@ -402,6 +420,51 @@ above.
 
 Fixes:
 
+- check: fix return code for index entry value discrepancies
+- benchmark: inherit options --rsh --remote-path, #8099
+- sdist: dynamically compute readme (long_description)
+- create: deal with EBUSY, #8123
+- No need to use OpenSSL 3.0 on OpenBSD, use LibreSSL.
+- fix Ctrl-C / SIGINT behaviour for pyinstaller-made binaries, #8155
+
+New features:
+
+- create: add the slashdot hack, update docs, #4685
+- upgrade --check-tam: check manifest TAM auth, exit with rc=1 if there are issues.
+- upgrade --check-archives-tam: check archives TAM auth, exit with rc=1 if there are issues.
+
+Other changes:
+
+- improve acl_get / acl_set error handling, improved/added tests, #8125
+- remove bundled lz4/zstd/xxhash code (require the respective libs/headers),
+  simplify setup.py, remove support for all BORG_USE_BUNDLED_*=YES, #8094
+- require Cython 3.0.3 at least (fixes py312 memory leak), #8133
+- allow msgpack 1.0.8, #8133
+- init: better borg key export instructions
+- init: remove compatibility warning for borg <=1.0.8
+  The warning refers to a compatibility issue not relevant any
+  more since borg 1.0.9 (released 2016-12).
+- locate libacl via pkgconfig
+- scripts/make.py: move clean, build_man, build_usage to there,
+  so we do not need to invoke setup.py directly, update docs
+- docs:
+
+  - how to run the testsuite using the dist package
+  - add non-root deployment strategy (systemd / capabilities)
+  - simplify TAM-related upgrade docs using the new commands
+- vagrant:
+
+  - use python 3.11.8
+  - use pyinstaller 6.5.0
+  - add xxhash for macOS, add libxxhash-dev for debianoid systems
+  - use openindiana/hipster box
+
+
+Version 1.4.0b1 (2024-01-21)
+----------------------------
+
+Fixes:
+
 - fix CommandError args, #8029
 
 New features:

borgbackup-1.4.0b2/docs/deployment/non-root-user.rst

@@ -0,0 +1,66 @@
+.. include:: ../global.rst.inc
+.. highlight:: none
+.. _non_root_user:
+
+================================
+Backing up using a non-root user
+================================
+
+This section describes how to run borg as a non-root user and still be able to
+backup every file on the system.
+
+Normally borg is run as the root user to bypass all filesystem permissions and
+be able to read all files. But in theory this also allows borg to modify or
+delete files on your system, in case of a bug for example.
+
+To eliminate this possibility, we can run borg as a non-root user and give it read-only
+permissions to all files on the system.
+
+
+Using Linux capabilities inside a systemd service
+=================================================
+
+One way to do so, is to use linux `capabilities
+<https://man7.org/linux/man-pages/man7/capabilities.7.html>`_ within a systemd
+service.
+
+Linux capabilities allow us to give parts of the privileges the root user has to
+a non-root user. This works on a per-thread level and does not give the permission
+to the non-root user as a whole.
+
+For this we need to run our backup script from a systemd service and use the `AmbientCapabilities
+<https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#AmbientCapabilities=>`_
+option added in systemd 229.
+
+A very basic unit file would look like this:
+
+::
+
+    [Unit]
+    Description=Borg Backup
+
+    [Service]
+    Type=oneshot
+    User=borg
+    ExecStart=/usr/local/sbin/backup.sh
+
+    AmbientCapabilities=CAP_DAC_READ_SEARCH
+
+The ``CAP_DAC_READ_SEARCH`` capability gives borg read-only access to all files and directories on the system.
+
+This service can then be started manually using ``systemctl start``, a systemd timer or other methods.
+
+Restore considerations
+======================
+
+When restoring files, the root user should be used. When using the non-root user, borg extract will
+change all files to be owned by the non-root user. Using borg mount will not allow the non-root user
+to access files that it would not have access to on the system itself.
+
+Other than that, the same restore process, that would be used when running the backup as root, can be used.
+
+.. warning::
+
+    When using a local repo and running borg commands as root, make sure to only use commands that do not
+    modify the repo itself, like extract or mount. Modifying the repo using the root user will break
+    the repo for the non-root user, since some files inside the repo will now be owned by root.

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/deployment.rst

@@ -14,3 +14,4 @@ This chapter details deployment strategies for the following scenarios.
    deployment/automated-local
    deployment/image-backup
    deployment/pull-backup
+   deployment/non-root-user

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/development.rst

@@ -199,6 +199,37 @@ Important notes:
 - When using ``--`` to give options to py.test, you MUST also give ``borg.testsuite[.module]``.
 
 
+Running the tests (using the pypi package)
+------------------------------------------
+
+Since borg 1.4, it is also possible to run the tests without a development
+environment, using the borgbackup dist package (downloaded from pypi.org or
+github releases page)::
+
+    # optional: create and use a virtual env:
+    python3 -m venv env
+    . env/bin/activate
+
+    # install packages
+    pip install borgbackup
+    pip install pytest pytest-benchmark
+
+    # method A: use a pytest.ini
+
+    cat >pytest.ini <<<EOF
+    [pytest]
+    python_files = testsuite/*.py
+    markers = allow_cache_wipe
+    addopts = -rs --benchmark-skip
+    EOF
+
+    pytest --pyargs borg.testsuite
+
+    # method B: give the options via the cmdline (each time you invoke the tests):
+
+    pytest -rs --benchmark-skip -o 'python_files=testsuite/*.py' -o 'markers=allow_cache_wipe' --pyargs borg.testsuite
+
+
 Adding a compression algorithm
 ------------------------------
 
@@ -220,8 +251,8 @@ for easier use by packagers downstream.
 When a command is added, a command line flag changed, added or removed,
 the usage docs need to be rebuilt as well::
 
-  python setup.py build_usage
-  python setup.py build_man
+  python scripts/make.py build_usage
+  python scripts/make.py build_man
 
 However, we prefer to do this as part of our :ref:`releasing`
 preparations, so it is generally not necessary to update these when
@@ -311,7 +342,11 @@ Checklist:
 - Check version number of upcoming release in ``CHANGES.rst``.
 - Render ``CHANGES.rst`` via ``make html`` and check for markup errors.
 - Verify that ``MANIFEST.in``, ``pyproject.toml`` and ``setup.py`` are complete.
-- ``python setup.py build_usage ; python setup.py build_man`` and commit.
+- Run these commands and commit::
+
+    python scripts/make.py build_usage
+    python scripts/make.py build_man
+
 - Tag the release::
 
     git tag -s -m "tagged/signed release X.Y.Z" X.Y.Z

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/global.rst.inc

@@ -15,7 +15,6 @@
 .. _libattr: https://savannah.nongnu.org/projects/attr/
 .. _liblz4: https://github.com/Cyan4973/lz4
 .. _libzstd: https://github.com/facebook/zstd
-.. _libb2: https://github.com/BLAKE2/libb2
 .. _OpenSSL: https://www.openssl.org/
 .. _`Python 3`: https://www.python.org/
 .. _Buzhash: https://en.wikipedia.org/wiki/Buzhash

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/installation.rst

@@ -180,7 +180,7 @@ following dependencies first:
 
   - Either pyfuse3_ (preferably, newer and maintained) or llfuse_ (older,
     unmaintained now). See also the BORG_FUSE_IMPL env variable.
-  - See setup.py about the version requirements.
+  - See pyproject.toml about the version requirements.
 
 If you have troubles finding the right package names, have a look at the
 distribution specific sections below or the Vagrantfile in the git repository,

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-benchmark-crud.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-BENCHMARK-CRUD" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-BENCHMARK-CRUD" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-benchmark-crud \- Benchmark Create, Read, Update, Delete for archives.
 .SH SYNOPSIS

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-benchmark.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-BENCHMARK" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-BENCHMARK" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-benchmark \- benchmark command
 .SH SYNOPSIS

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-break-lock.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-BREAK-LOCK" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-BREAK-LOCK" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-break-lock \- Break the repository lock (e.g. in case it was left by a dead borg.
 .SH SYNOPSIS

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-check.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-CHECK" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-CHECK" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-check \- Check repository consistency
 .SH SYNOPSIS
@@ -161,7 +161,7 @@ See \fIborg\-common(1)\fP for common options of Borg commands.
 .B REPOSITORY_OR_ARCHIVE
 repository or archive to check consistency of
 .UNINDENT
-.SS options
+.SS optional arguments
 .INDENT 0.0
 .TP
 .B  \-\-repository\-only

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-common.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-COMMON" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-COMMON" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-common \- Common options of Borg commands
 .SH SYNOPSIS

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-compact.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-COMPACT" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-COMPACT" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-compact \- compact segment files in the repository
 .SH SYNOPSIS
@@ -66,7 +66,7 @@ See \fIborg\-common(1)\fP for common options of Borg commands.
 .B REPOSITORY
 repository to compact
 .UNINDENT
-.SS options
+.SS optional arguments
 .INDENT 0.0
 .TP
 .B  \-\-cleanup\-commits

{borgbackup-1.4.0b1 → borgbackup-1.4.0b2}/docs/man/borg-compression.1

@@ -27,7 +27,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
 ..
-.TH "BORG-COMPRESSION" 1 "2024-01-20" "" "borg backup tool"
+.TH "BORG-COMPRESSION" 1 "2024-03-30" "" "borg backup tool"
 .SH NAME
 borg-compression \- Details regarding compression
 .SH DESCRIPTION