Skip to content

fix(security): AVATAR_PROXY_MAX_BYTES read like a cap and gated only caching - #112

Merged
pitimon merged 2 commits into
mainfrom
fix/110-avatar-body-cap
Jul 25, 2026
Merged

fix(security): AVATAR_PROXY_MAX_BYTES read like a cap and gated only caching#112
pitimon merged 2 commits into
mainfrom
fix/110-avatar-body-cap

Conversation

@pitimon

@pitimon pitimon commented Jul 25, 2026

Copy link
Copy Markdown
Owner

Summary

Closes #110 item 7. Pre-existing defect, found while closing the round-3 port finding on #109 and deliberately kept out of that PR.

AVATAR_PROXY_MAX_BYTES read like a download cap. It was not one:

const body = Buffer.from(await upstream.arrayBuffer());   // whole body, first
if (body.length <= AVATAR_PROXY_MAX_BYTES) {              // gates CACHING only

The check decided only whether the result entered avatarProxyCache. An oversized response was still read into memory in full and still written to the client, so an allowlisted host serving a very large image/* drove loopback-server memory with no ceiling.

The fix

readCappedAvatarBody() reads at most maxBytes and stops there. Two gates, because either alone is soft:

  • content-length is a claim the peer makes, and can be omitted or wrong. Checking it costs nothing and refuses before a byte is transferred.
  • A running byte count, because trusting the claim is not an option.

Returning from the for await calls the iterator's return(), which cancels the stream.

Measured, not asserted

A 5120-byte body against a 1024-byte cap now reads 1280 bytes — one chunk past the limit, which is inherent: a chunk cannot be known to overrun until it has arrived. So this is bounded at cap + one chunk, not "stops exactly at the cap".

Behaviour change

An over-cap avatar is now refused with 413 rather than served and merely not cached. 512 KiB is far above any real avatar, and the dashboard falls back to its local icon on a failed image load.

Test plan

  • ci:local exit 0 — 889 root tests (+6), 256 dashboard
  • An over-cap content-length is refused with the body never touched (the stub records every pull; asserted empty)
  • A body exceeding the cap mid-stream stops early — asserted fewer chunks pulled than the body contains
  • A lying content-length (declares 10, sends 1536) does not get past the byte count
  • A body exactly at the cap is allowed — not off by one
  • The no-stream path (HEAD, stubs) is bounded too
  • openwiki-facts/source-facts.json regenerated for the new export

…caching

Closes #110 item 7. Pre-existing; found while closing the round-3 port finding
on #109, and deliberately left out of that PR.

The whole upstream body was buffered with arrayBuffer() first, and the constant
then only decided whether the result entered avatarProxyCache. An oversized
response was still read into memory in full and still written to the client, so
an allowlisted host serving a very large image/* drove loopback-server memory
with no ceiling.

readCappedAvatarBody() reads at most maxBytes and stops there. Two gates,
because either alone is soft: content-length is a claim the peer makes and can
omit or lie about, so check the claim AND count the bytes. Returning from the
for-await calls the iterator's return(), which cancels the stream.

Measured: a 5120-byte body against a 1024-byte cap now reads 1280 bytes — one
chunk past the limit, which is inherent since a chunk cannot be known to
overrun until it has arrived. Not "stops exactly at the cap"; bounded at
cap + one chunk.

Behaviour change: an over-cap avatar is now REFUSED with 413 rather than served
and merely not cached. 512 KiB is far above any real avatar, and the dashboard
falls back to its local icon on a failed image load.

6 tests, including that an over-cap content-length is refused with the body
never touched, that a lying content-length does not get past the byte count,
that a body exactly at the cap is allowed, and that the no-stream path is
bounded too.

ci:local exit 0: 889 root tests, 256 dashboard.
@pitimon
pitimon merged commit e6fb9eb into main Jul 25, 2026
1 check passed
@pitimon
pitimon deleted the fix/110-avatar-body-cap branch July 25, 2026 21:58
pitimon added a commit that referenced this pull request Jul 26, 2026
15 commits since v0.39.43. Tracker: #125.

User-facing:
- The Projects panel honours the date range. It read no query parameter at
  all, so picking "24h" narrowed every other card while Projects kept showing
  all-time totals with nothing on screen saying so (#118).
- Per-repo cost, with rows written before the change named as unpriced rather
  than shown as a confident $0 (#121).
- Sources with no per-repo attribution are named, instead of their absence
  reading as "that tool cost nothing here" (#118).
- A plan-value card answering what README:32 already promised, labelled as
  list-price-equivalent rather than a saving (#122).
- The Codex quota chip no longer vanishes on a 401 (#119).
- `sync --compact`, which reclaimed 34,924 lines to 5,636 on a real install
  (#117).

Behind the scenes: outbound-privacy validator hardening (#111, #114), avatar
proxy per-hop revalidation, port-aware allowlisting and a real download cap
(#109, #112), a parser conformance ratchet (#116, #120), scripts/graph out of
the product gate (#115), and a usage-limits fixture capture tool (#124).

Version bumped in all four lockstep locations by the `version` hook:
package.json, package-lock.json, both TokenTrackerBar targets, and the Windows
csproj. validate:version-lockstep passes.

WATCH AFTER SHIPPING: #121 migrates cursors.json on every user's first sync
after upgrading, re-keying project buckets from project|source|hour to
project|source|model|hour. Without that the old bucket strands and its usage is
counted twice. Verified read-only against a real 2,015-bucket state — every key
migrated, total_tokens preserved exactly at 6,281,653,062, and all 2,015
queuedKey markers survived, the loss of which would re-append every row. That
is one machine; a differently-shaped state is the residual risk.

ci:local exit 0: 972 root tests, 302 dashboard.

Co-authored-by: itarun.p <itarun.p@somapait.com>
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