Skip to content

fix: bound network response body reads - #770

Merged
marccampbell merged 2 commits into
mainfrom
fix/limit-network-response-bodies
Jul 29, 2026
Merged

fix: bound network response body reads#770
marccampbell merged 2 commits into
mainfrom
fix/limit-network-response-bodies

Conversation

@marccampbell

@marccampbell marccampbell commented Jul 27, 2026

Copy link
Copy Markdown
Member

Why this matters

Some production paths buffered entire network response bodies with unbounded io.ReadAll. For small, fixed-shape payloads (token JSON, CMX metadata, checksum text, OCI manifests), a modest ceiling is a reasonable guard without changing normal product behavior.

Review feedback

Vendor API responses in pkg/platformclient are not limited. Per review: this is a short-lived CLI against a trusted Vendor API; a hard cap can turn a successful large release payload into a client error without meaningful security benefit. That change was dropped.

What remains bounded

Path Limit Rationale
Login token exchange 1 MiB Token JSON only
CMX MMDS metadata + token 1 MiB Small credential payloads
Helm/troubleshoot checksum files 1 MiB Text checksum lists
OCI model manifest 16 MiB Manifest JSON, not layers

Explicit non-goals

  • No limit on Vendor API client responses (platformclient)
  • No limit on CLI stdin release YAML
  • No limit on tool binary/archive downloads

Test plan

  • go test ./pkg/platformclient/ ./pkg/credentials/ ./pkg/tools/ ./cli/cmd/
  • Platform client uses unbounded io.ReadAll again (no size cap)

Limit allocation on Vendor API, login token, CMX metadata, checksum, and
OCI manifest response bodies with generous ceilings that preserve normal use.
Comment thread pkg/platformclient/client.go Outdated
return nil
}

func readAllLimited(r io.Reader, limit int64) ([]byte, error) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems unnecessary. This can potentially turn a successful API request into an error causing the client to retry. But also this is a CLI tool, not a long running service, so response size should not be a major issue.

Per review: this is a short-lived CLI talking to a trusted Vendor API.
Hard caps can turn successful large responses into client errors without
real security benefit. Keep limits only on small fixed-shape payloads.
@marccampbell
marccampbell merged commit f458f88 into main Jul 29, 2026
7 checks passed
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.

2 participants