Skip to content

fix(reliability): bound inline image validation without decoding oversized base64 #165

Description

@seonghobae

Current authoritative state

Protected shipped truth is exact main@3b38ead2d00f44eb578d0689087b9293b3dabe1e. This inline-raster allocation/resource defect is repaired on canonical Draft PR #166 / branch fix/inline-image-size-preflight-20260811, which explicitly Closes #165 (and #274). Current exact Draft head is f0e1a2e641d5372b4e333361ee015593caeb7cc9; the branch is non-destructively synchronized with protected main and its effective product delta is limited to src/policy/inlineImagePolicy.ts plus its dedicated preflight test.

Implemented active-PR contract

validateInlineImageSource() no longer decodes an otherwise-valid oversized base64 payload merely to determine decoded size. The active implementation uses a bounded MIME/data-URI prefix recognizer, validates canonical base64 incrementally without whole-source regex work, derives exact decoded bytes from validated source length and padding, and raises the existing Base64SizeError with exact bytes / maxBytes values when the configured ceiling is exceeded. Malformed-source precedence remains Base64ImageSourceError, including malformed oversized inputs.

The same canonical owner also closes the public byte-limit defect in #274: maxSizeBytes must be a non-negative safe integer, with 0 preserving the documented size-limit-disable behavior. NaN, negative, fractional, infinite, and unsafe-integer ceilings fail closed through one payload-redacted RangeError before source-size comparison. Accepted raster MIME aliases/case, valid-source identity, Markdown/HTML/editor image behavior and error redaction remain preserved.

The repair does not modify the separately owned converter/base64 Blob boundary and adds no transport, persistence, credentials, tenancy, authorization, collaboration-provider, model/network, deployment, retention, durable-audit or host-policy authority.

Verification / integration boundary

#166 records the test-first lineage and exact active-head verification. Its current exact-head repository evidence is CI 32073713863 completed / success, Security Scan 32073713918 completed / success, and SAST Semgrep 32073713735 completed / success; formal submitted reviews and unresolved inline review threads are 0. Repository technical success is not qualifying independent approval, and predecessor/absent/status/model evidence does not transfer.

Keep this issue open until #166 integrates under then-live protected-main governance. Keep #166 Draft/unmerged while #118 owns exact protected v0.6.0 tag/publication/provenance/registry-digest acceptance. Do not create a competing inline-image writer, self-approve, weaken gates, move protected main, or represent this active-PR behavior as shipped.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: apiAPI, protocol, event, or external contractarea: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: securitySecurity boundary, hardening, or vulnerability preventionpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: bugDefect or incorrect behavior

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions