Patch blob and diff downloads buffer the whole response body with no size cap
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 84/100
Rechercherichtung
Beginne in crates/socket-patch-core/src/api/client.rs bei ApiClient::fetch_binary, lies anschließend utils/http.rs und die bestehende Behandlung von Vendor-Downloads zur Fehlerzuordnung für capped-reader. Führe die benannten Blob- und Binary-Fetcher-Tests vor den Änderungen aus. Als erledigt gilt die Änderung, wenn übergroße Blob- und Diff-Antworten am Limit fehlschlagen, ohne unbegrenztes Puffern, während die aufgeführten e2e-Tests weiterhin erfolgreich sind.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
[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.
- Vorherrschende Sprache
- Rust
- Sterne
- 8
- Forks
- 0
- Ø Merge
- 15 Std. 39 Min.
- Gemergte PRs (30 T.)
- 104
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus SocketDev/socket-patch
-
agent:triaged bug bughunt pm:cargo priority:p2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
SocketDev/socket-patch#651 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 88/100
SocketDev/socket-patch#613 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:composer priority:p2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
SocketDev/socket-patch#515 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:npm priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SocketDev/socket-patch#464 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:npm priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SocketDev/socket-patch#433 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in SocketDev/socket-patch
Ähnliche Issues
-
area:release bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
registrystack/registry-stack#1874 ·
Maintainer antworten meist innerhalb von 1 Tag
-
component:midnight-toolkit status:untriaged
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
midnightntwrk/midnight-node#2237 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag