The current recovery path derives allocations and reconstruction/decompression work from server-returned blob metadata. An application integrating this as an encrypted archive needs documented, enforced limits before allocation and decompression.
Please consider a versioned safe-retrieval profile or SDK options that bound and validate:
- total shard count and duplicate/out-of-range shard indices;
- raw/sealed shard size, ciphertext length, and aggregate response bytes;
- declared plaintext and decompressed output bytes;
- compression ratio / decompression work;
- deadline/cancellation behavior; and
- binding the response metadata and recovered plaintext to the requested object identifier.
The API should fail before oversized allocation, reconstruction, or decompression. These controls matter even when payload confidentiality holds: a malicious or compromised storage node can otherwise create client-side memory, CPU, and cost denial of service.
The current recovery path derives allocations and reconstruction/decompression work from server-returned blob metadata. An application integrating this as an encrypted archive needs documented, enforced limits before allocation and decompression.
Please consider a versioned safe-retrieval profile or SDK options that bound and validate:
The API should fail before oversized allocation, reconstruction, or decompression. These controls matter even when payload confidentiality holds: a malicious or compromised storage node can otherwise create client-side memory, CPU, and cost denial of service.