`Limits::depth(n)` (added in 9b78182) leaves `len` at `usize::MAX`, so XDR reads and writes were still unbounded in size — the actual gap left open by stellar#103. This closes it: - Decoding untrusted RPC responses uses `xdr_decode_limits(input.len())`: a length budget derived from the input itself, per soroban-env-host's explicit guidance not to reuse its default length for deserialization. This bounds amplification (a tiny payload lying about a huge internal vector) without ever rejecting a legitimately large response. - Encoding transactions this crate constructs uses `xdr_encode_limits()`, a fixed 32 MiB budget that actually matches soroban-env-host's `DEFAULT_XDR_RW_LIMITS` (an earlier draft of this fix claimed 16 MiB, which was both wrong and, per upstream's own comment, the wrong constant to reuse for decoding in the first place). - `HttpClientBuilder` now sets `max_response_size` explicitly instead of inheriting jsonrpsee's default, so the outer bound `xdr_decode_limits` derives from is a deliberate choice. - `get_ledger_entries` no longer encodes each key twice, and surfaces a real `LengthLimitExceeded`/`DepthLimitExceeded` instead of a generic `XdrError::Invalid`. Tests pin the actual measured depth boundary (500 units of `XDR_DEPTH_LIMIT` trips at nesting level 125, not the deep nesting values used in the initial draft), verify the length budget rejects a payload that lies about its own size, and document the existing behavior of silently dropping events that fail to decode. Closes stellar#103 Co-authored-by: Nearx-Labs <nearxlabs@nearx.com.br>

Uh oh!

Add limits to XDR parsing #103

Description

What

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions