Selected-artifact checksum repair — 2026-10-24¶
PR #469 merged the first recovery contract repair. The next bounded slice, PR #470, addresses INC-003: checksum verification must cover the recovery copy selected for import, not its historical source path. Source implementation and synthetic validation do not establish deployment or application recovery acceptance.
What changed¶
OneUptime, the incident adapter and the remediation broker now use a shared checksum verifier before their restore drills make any Docker call, including inspection or cleanup. It hashes the explicitly selected dump and requires the adjacent checksum sidecar. The filename recorded inside the sidecar is checked for identity but is never followed to choose another file.
New backup runs produce basename-relative sidecars. Valid old absolute-path records remain usable after relocation without changing retained backups. Missing or malformed records, a different filename and mismatched bytes fail closed; adapter/broker drills no longer silently skip missing checksums.
The operating guides specify the supported record format, full-checkout/Python requirements and how to recover a trusted missing sidecar. Generating a fresh checksum from untrusted restored bytes is not a valid way to pass the gate. Checksums establish byte agreement, not authenticity, freshness, database consistency or application recoverability.
Validation and phase status¶
Synthetic tests keep the original dump intact while corrupting only the relocated copy and require refusal before any Docker invocation. Other tests cover valid legacy/new records, missing/malformed/multiple/wrong-filename records, regular-file constraints, streamed hashing and all three writers. Workflow tests use fake Docker and stop a valid drill at its first Docker operation; they are not successful database restores.
| Area | Status | Remaining gate |
|---|---|---|
| PR #469 | Merged; REC-001 remains implemented | Observe effective units and new local/offsite snapshots, then validate application recovery and rollback |
| INC-003 checksum slice | Source changes and synthetic regression tests in PR #470 | Review exact-head CI and implementation evidence before merge |
| Live verification | Not established | Read-only SSH stopped at strict host-key verification; establish trusted host identity before retrying |
| Application recovery | Not performed | Approved isolated database restore, integrity and rollback checks |
| Other audit concerns | Separate backlog | No unrelated finding or workstream is closed by this repair |
The failed SSH attempt ran no remote commands. Host-key checking was not disabled and no unverified key was enrolled. Agents can continue source repair and record results; the owner/operator must supply or establish a trusted access path and approve deployment and recovery exercises. The immutable audit and prior session records remain intact, with current evidence linked from the private registry in the repository README.
flowchart TD
Merge[PR 469 merged] --> Scope[INC-003 source repair]
Scope --> Tests[Synthetic checksum and workflow regressions]
Tests --> Review[Review PR 470 and exact-head CI]
Review --> Deploy[Approved deployment with trusted host access]
Deploy --> Drill[Isolated application integrity and rollback checks]
Drill --> Accept[Record owner acceptance separately]Operating guidance¶
No live backup, production container, database restore, offsite repository, credential decryption, backup cleanup or merge was performed in this slice. Existing snapshot-set rules, image/secret prerequisites and other restore limitations remain independent acceptance requirements.