repo-create: always write config/defaults, so its removal is detected, refs #346 - #10441
Merged
ThomasWaldmann merged 1 commit intoSep 27, 2026
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #10441 +/- ##
==========================================
+ Coverage 88.66% 88.68% +0.01%
==========================================
Files 103 103
Lines 19284 19305 +21
Branches 3004 3005 +1
==========================================
+ Hits 17099 17120 +21
Misses 1515 1515
Partials 670 670 ☔ View full report in Codecov by Harness. |
…, refs borgbackup#346 Without the object, the commands silently fell back to the built-in defaults, so anybody with write access to the store could remove a repository default (e.g. an "obfuscate" compression) unnoticed: the key protects the content of the object, not its presence. Now "borg repo-create" always writes config/defaults (empty if no default was given), and a missing object is an error (Repository.DefaultsMissing, rc 34) like one that fails the authentication: the commands using the defaults refuse to run. "borg check" reports such an object, "borg check --repair" replaces it by empty defaults, so the repository can be used again (with the built-in defaults). with_repository reads the defaults only after the security checks (assert_secure). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ThomasWaldmann
force-pushed
the
repo-defaults-mandatory
branch
from
September 27, 2026 15:10
041fd7e to
26ff43f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #10438 (refs #346): make the repository defaults object mandatory, so that its removal is detected.
Problem
#10438 stores the repository defaults (compression, chunker params) in
config/defaults, in the key's store object envelope, and claimed that nobody without the key can change them unnoticed. That holds for the content of the object, but not for its presence: a missing object meant "no defaults", so anybody with write access to the store could simply delete it, and the nextborg createsilently fell back to the built-in defaults - e.g. dropping anobfuscatecompression. Reproduced:rm repo/config/defaults→borg createrc 0, archive stored with lz4 and the built-in chunker params, no warning.Change
borg repo-createalways writesconfig/defaults, also when no default was given (an empty dict).Repository.DefaultsMissing(new rc 34, message with a hint). The commands that use the defaults (create,recreate,import-tar,transfer,repo-compress,debug put-obj,repo-info) refuse to run. Giving every default explicitly (--compressionand--chunker-params) still works, as the object is not read then.borg checkverifies the object (present, authenticates, deserializes) and reports it;borg check --repairreplaces a missing or corrupt object by empty defaults, so the repository can be used again (with the built-in defaults; the set defaults are lost - like the repository config, they can not be restored). The check lives indo_check(the command), not inRepository.check(): the latter is also used on API-created repositories withoutrepo-create, which have no defaults object.with_repositoryreads the defaults only afterassert_secure()passed. (This also keeps the repository swap detection tests raisingEncryptionMethodMismatch: the repository id is part of the envelope AAD, so after a swap the defaults object fails authentication first otherwise.)IntegrityErrorfor a tampered object now carries theborg check --repairhint, too.Impact on existing beta repositories
Repositories created before this change have no
config/defaults: every command using the defaults fails with rc 34 untilborg check --repair(orborg check --repair --repository-only, which still hashes all packs - server-side forssh://) has stored empty defaults, or the repository is recreated. In line with the beta policy, there is no compatibility fallback: a fallback would be exactly the hole this PR closes.Docs / tests
Docs:
repo-createandcheckepilogs,data-structures.rst(config/namespace, envelope paragraph, "Repository defaults"), the rc list infrontends.rst.Tests:
test_defaults_missing(create/repo-info refuse, explicit options still work),test_check_repository_defaults[missing|corrupt](check reports,--repairrestores, repository usable again). Full test suite passes locally (macOS, Python 3.11), except the known localtest_migrate_lock_alivemacFUSE failure.Follow-ups (not in this PR)
repo-createsets them, by decision).checkdoes not validate the values of the defaults (an invalid stored spec still fails at use time with rc 16).🤖 Generated with Claude Code