monitor: publish signed+sealed state reports for monitoring#9788
Draft
ThomasWaldmann wants to merge 7 commits into
Draft
monitor: publish signed+sealed state reports for monitoring#9788ThomasWaldmann wants to merge 7 commits into
ThomasWaldmann wants to merge 7 commits into
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #9788 +/- ##
==========================================
- Coverage 84.70% 80.66% -4.05%
==========================================
Files 92 95 +3
Lines 15172 15440 +268
Branches 2279 2315 +36
==========================================
- Hits 12852 12454 -398
- Misses 1617 2302 +685
+ Partials 703 684 -19 ☔ View full report in Codecov by Harness. |
ThomasWaldmann
force-pushed
the
monitoring
branch
from
4006d72 to
41e69cc
Compare
ThomasWaldmann
force-pushed
the
monitoring
branch
from
41e69cc to
7a6876a
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
ThomasWaldmann
force-pushed
the
monitoring
branch
from
3f2e65b to
2b1f6a1
Compare
After create/prune, the borg client now publishes a small state report into the repository's new `monitoring/` namespace. The report is signed (Ed25519) and sealed (HPKE, RFC 9180) using key material derived from the existing borg key, so the untrusted repository server can neither forge nor read it - it can only relay it. The new `borg monitor` command reads, verifies and decrypts the reports from from the repository using the monitoring key, applies a freshness window (--max-age) and exits non-zero if the report is missing, stale, unsigned or unsuccessful. `borg monitor --key` (which needs the unlocked borg key) derives and prints BORG_MONITORING_KEY for the monitoring host; that value only allows verifying and decrypting the state reports, not creating them. It also does not give access to other data or metadata in the repository. Unencrypted (`--encryption none`) repos have no key to derive the monitoring key from, so their reports are published as unsigned, unencrypted plaintext and these reports are flagged untrusted on read. Requires OpenSSL >= 3.2 (for the built-in HPKE API). borg monitor --json outputs report(s) in json format. borg monitor --keep=N keeps the latest N status reports (default: 500), older reports are deleted. --keep=0 disables this. borg monitor reads all reports and prints, per archive series (and per maintenance command), the latest status and freshness; --name / --command restrict the output. The exit code is the worst across all units. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The low_level Ed25519/HPKE length-validation guards and the monitoring key derivation hardcoded the byte sizes (32) that the exported ED25519_*/X25519_* size constants already document. Reference the constants instead, which also puts the two so-far-unused ones (ED25519_SEED_SIZE, X25519_PUBLIC_SIZE) to use. Sizes are unchanged; C array dimensions stay literal as Cython requires. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reports now include the hostname and username of the backup (for create, the archive's own host/user; for repo-wide commands like prune, the local host/user). borg monitor groups reports by (host, user, command, archive series) and reports each distinct backup job independently, so several hosts backing up the same archive series name to one repository no longer mask each other. New --host and --user options restrict the output (alongside --name and --command); the JSON entries expose hostname/username/command/archive. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
borg delete, borg undelete and borg transfer now publish a monitoring report as the last action while the store is open (skipped on --dry-run), with host/user defaulting to the local machine like prune. Stats record the number of archives deleted / undeleted / transferred (plus considered/skipped and transferred bytes). These appear as their own units in borg monitor (command=delete / undelete / transfer). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ThomasWaldmann
force-pushed
the
monitoring
branch
from
2b1f6a1 to
5d10236
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
2 participants
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.
After create/prune, the borg client now publishes a small state report into the repository's new
monitoring/namespace. The report is signed (Ed25519) and sealed (HPKE, RFC 9180) using key material derived from the existing borg key, so the untrusted repository server can neither forge nor read it - it can only relay it.The new
borg monitorcommand reads, verifies and decrypts the reports from from the repository using the monitoring key, applies a freshness window (--max-age) and exits non-zero if the report is missing, stale, unsigned or unsuccessful.borg monitor --key(which needs the unlocked borg key) derives and prints BORG_MONITORING_KEY for the monitoring host; that value only allows verifying and decrypting the state reports, not creating them. It also does not give access to other data or metadata in the repository.Unencrypted (
--encryption none) repos have no key to derive the monitoring key from, so their reports are published as unsigned, unencrypted plaintext and these reports are flagged untrusted on read.borg monitor --json outputs report(s) in json format.
borg monitor --keep=N keeps the latest N status reports (default: 500), older reports are deleted. --keep=0 disables this.
borg monitor reads all reports and prints, per archive series (and per maintenance command), the latest status and freshness; --name / --command restrict the output. The exit code is the worst across all units.
Requires OpenSSL >= 3.2 (for the built-in HPKE API).