Skip to content

Revoke private-channel attachment access after removal - #7565

Draft
jmecom wants to merge 1 commit into
mainfrom
jm/revoke-private-channel-attachment-access
Draft

Revoke private-channel attachment access after removal#7565
jmecom wants to merge 1 commit into
mainfrom
jm/revoke-private-channel-attachment-access

Conversation

@jmecom

@jmecom jmecom commented Sep 10, 2026

Copy link
Copy Markdown
Collaborator

Gate attachment GET/HEAD requests, including ranges and thumbnails, on current event and channel access from the primary database. Removing a member from a private channel now prevents further downloads through saved attachment URLs. This addresses the attachment issue in the report.

Reject publications that would restore access by copying an inaccessible local URL into a profile or another channel. Record successful uploads after verifying their bytes so legitimate reuploads still work. Unposted media and attachments also shared in readable events retain their existing access.

The migration indexes existing event references. Fresh-schema setup creates and verifies the same index through the existing reconciliation script. Media responses use private, no-store; previously downloaded bytes cannot be recalled.

Passed all five attachment regressions, 122 database unit tests, fresh-schema parity/reconciliation, formatting, workspace and targeted Clippy, both desktop Clippy configurations, and the file-size gate. The full unit phase of just test passed. just ci recorded an intermittent timeout in the unrelated ACP test blocked_recovery_write_is_bounded_and_retains_loss; it passed on subsequent runs. The broader integration suite could not start because Docker Desktop requires sign-in on this machine.

Signed-off-by: Jordan Mecom <jm@squareup.com>
@github-actions

Copy link
Copy Markdown

🔐 Codex Security Review

Status: review required for the current range.

The current range is cec5c8fd9280d30f56effac701e1e19d5cfe6fea...2f40f6731f13c4e5566a48002795f53e0e7073b7.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 2f40f6731f13c4e5566a48002795f53e0e7073b7 to authorize a new review.
Any previous review applies only to its recorded range.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant