#199: SHA-256 integrity hashes for attachments #259
No reviewers
Labels
No Label
area:auth
area:docs
area:export
area:ops
area:storage
area:supply-chain
auth
backend
blocked
collab
deployment
docs
effort:L
effort:M
effort:S
frontend
plugins
qa
vs-nfd
vs-nfd:blocker
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: stwaidele/dorfteich#259
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/199-attachment-integrity-hashes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Stacked on #258 (#202) -> #257 (#236). Issue #199.
attachments.sha256(nullable) added by migration; upload computes the hash from the in-memory buffer being written (never re-reads disk).attachment_integrity_failure(HTTP 500); the mismatch is audited asfile.integrity_failedwith both hashes. Null-hash rows (pre-backfill) are served unverified — the pre-#199 status quo.attachment-integrity.e2e.db.test.ts): upload stores the correct hash; on-disk tamper makes download fail closed with the code + audit row; backfill restores hashes, keeps unreadable rows null, and is idempotent. Full api suite green (476) against a fresh DB;migrate deployverified on a second fresh DB.