fix(server): fail closed on unreadable attachment size - #8
Merged
Conversation
download_attachment treated a missing/non-numeric metadata size as 0, which always passed the max_attachment_bytes check, so an upstream field omission voided the operator's resource bound (I4, fail-closed). The cap gate is now Option-aware in jirakeep-core (unknown size refused when a non-zero cap is set; cap 0 still unlimited) and the download itself is streamed with a Content-Length precheck plus a per-chunk byte-count abort.
plusky
added
security
plusky
enabled auto-merge (rebase)
August 8, 2026 19:51
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
1 participant
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.
download_attachmentread the attachment size withunwrap_or(0), and0passesattachment_within_capfor every cap — so metadata with a missing, null, or non-numericsizebypassedglobal.max_attachment_bytesentirely, and the full body was downloaded and base64-returned with no re-check. The trigger is upstream-controlled, which made the operator's resource bound not a bound.With a non-zero cap the decision is now fail-closed on unreadable size (I4), and the actually-downloaded byte count is enforced as a backstop so an understated
sizecannot exceed the cap either.cap == 0keeps meaning unlimited; the upload path already checked real lengths and is unchanged.Invariants: I4 (fail-closed on unreadable metadata, applied to the resource bound), I2 (refusal stays within what the guard already decided).
Tests: core unit tests for the
Option-aware cap decision plus coverage that unreadable-size metadata refuses before any download; confirmed to fail against the unfixed code.Process: AI-assisted — implemented and independently adversarially reviewed against
docs/DESIGN.md(verdict: approve, with an empirical pre-fix-failure check). Full verification suite green at the commit.