Uh oh!
There was an error while loading. Please reload this page.
fix(security): [OBE-10709,OBE-10718,OBE-11236] bound gcs and wef allocation paths - #144
Closed
JuanMantica45 wants to merge 3 commits into
Closed
fix(security): [OBE-10709,OBE-10718,OBE-11236] bound gcs and wef allocation paths#144JuanMantica45 wants to merge 3 commits into
JuanMantica45 wants to merge 3 commits into
Conversation
Bumps the private submodule. Contents: stcp - max_frame_bytes bounds the per-connection receive buffer, defaulting to 4x max_event_size. The cap covers a partially-read frame plus anything the peer pipelined behind it, so at parity with max_event_size a single legitimate max-size event arriving with one trailing byte would close the connection. - max_lines_per_event (1e6) bounds the O(N*M) clone amplification from a large RAW field with many newlines combined with a large field map. - read_leb128_i64 returned Ok(0) on buffer exhaustion, a silent truncation that let a zero count bypass downstream loop guards; it now returns InSufficientData so the framer waits for more bytes. - `warn!` was used without being imported, so the crate did not compile. gcs - max_decompressed_bytes (4 GiB) caps decompressor output. Objects are streamed line-by-line and never buffered whole, so this is a runaway-decompressor guard rather than the memory bound; it sits above documented producer maxima (BigQuery exports 1 GB uncompressed per file, Cloud Logging 3.5 GiB) so real objects are not truncated. Truncation is logged and counted. wef - max_content_length is enforced on the HTTP body via Limited. It and max_envelope_size are independent settings, so the enforced value is max(configured, 4x largest advertised envelope) -- otherwise raising the advertised size alone would 413 every batch. The body is strictly larger than the envelope it carries: the Kerberos path adds multipart framing and a GSS wrap header. - sldc::decompress returns a typed SizeLimitExceeded. Both call sites treated any error as "input was not compressed" and fell back to the raw bytes, so an oversized stream was silently reinterpreted as plaintext UTF-16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… to gcs/wef-only bounds branch Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Bumps `lib/observo/private`. Depends on `dataplane-private` PR #69 (branch `gcs-wef-oom-bounds`).
gcs
wef
Testing
`wef` 119 · `gcs` 7 — all passing.
Jira: OBE-10709, OBE-10718, OBE-11236