Patch blob and diff downloads buffer the whole response body with no size cap
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 84/100
Direzione di ricerca
Inizia da crates/socket-patch-core/src/api/client.rs, in ApiClient::fetch_binary, poi leggi utils/http.rs e la gestione esistente dei download dei vendor per la mappatura degli errori di capped-reader. Esegui i test indicati per blob e binary fetcher prima di apportare modifiche. Il lavoro è completato quando le risposte blob e diff sovradimensionate falliscono al raggiungimento del limite senza buffering illimitato, mentre i test e2e elencati continuano a passare.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.
Kind: bug. Source: new finding (not in the October review); register C37.
Problem
ApiClient::fetch_binary, which backs fetch_blob and fetch_diff, reads a 200 response with resp.bytes().await and applies no bound (api/client.rs#L1089-L1099). The bytes are hash-checked only after they are fully in memory.
The crate already has a shared capped body reader for this. utils::http::read_capped / read_capped_typed (utils/http.rs#L22-L40) rejects an over-large Content-Length and an over-long stream. Its doc says it was hoisted "so the self-update downloader shares the exact cap semantics". It is used by:
- the vendor package download, with
MAX_VENDOR_PACKAGE_BYTES= 256 MiB, described as a "defensive bound against a runaway / hostile serve response" (#L1689-L1692,#L1783-L1785); - the artifact download (
#L2796-L2798); - self-update archives and metadata (
update/download.rs#L100,update/release.rs#L408).
The patch blob and diff path, which is the one every apply/get hits, bypasses it. The diff archive's decompressed size is capped later, at 64 MiB in patch/package.rs, but the download itself is not.
Reproduced twice on main @ 1169ae6 with an integration test against ApiClient (not committed). A local server answers the authenticated blob URL with a 600 MiB application/octet-stream body. fetch_blob returned Ok(Some(len = 629145600)), buffering 600 MiB, more than twice the cap the vendor path enforces on the same client.
Symptoms
None filed.
Impact
A misbehaving or hostile endpoint can exhaust memory with one response: a mis-set --api-url/SOCKET_API_URL, a proxy, or the public patch proxy serving a wrong file. The blob is rejected afterwards anyway. This is low-to-medium risk, a consistency defect with a small fix.
Proposed change
- In
fetch_binary, replaceresp.bytes()withread_capped_typed(resp, MAX_PATCH_BLOB_BYTES, kind)and mapCapExceeded/TruncatedontoApiErrorthe way the vendor path does. - Choose one named cap. 64 MiB matches the per-file cap the patch engine applies elsewhere (
MAX_FILE_BYTES,patch/package.rs). - No new reader. This deletes the last uncapped
bytes()body read inapi/.
Size and scope
api/client.rs, ~15–30 production lines plus one test. Out of scope: timeouts (#570) and retry for blob/diff (C15).
Acceptance criteria
- Regression tests: a blob response over the cap, either by
Content-Lengthor by stream length, returns an error without buffering past the cap. A diff response gets the same test. -
binary_fetch_error_classification_e2e,blob_fetcher_edges_e2eandcovgap_api_blob_fetcherstay green.
Dependencies
None. It is best landed with or next to #570 because both touch fetch_binary.
- Lingua principale
- Rust
- Stelle
- 8
- Fork
- 0
- Merge medio
- 1g 1h
- PR unite (30g)
- 257
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di SocketDev/socket-patch
-
agent:triaged bug bughunt pm:npm priority:p1
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
SocketDev/socket-patch#1127 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged bug bughunt pm:bundler priority:p1
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
SocketDev/socket-patch#1125 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged bug bughunt pm:pipenv priority:p1
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 85/100
SocketDev/socket-patch#1122 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged bug bughunt pm:npm priority:p1
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
SocketDev/socket-patch#1072 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged arch-audit bug priority:p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
SocketDev/socket-patch#1062 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di SocketDev/socket-patch
Issue simili
-
[Feature] 设置里面的同步功能Apertaenhancement user-priority/P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
containers/aardvark-dns#743 ·