Skip to content

from_oci: Validate Content-Range response header when resuming blob downloads to prevent silent data corruption #10

@coderabbitai

Description

@coderabbitai

Summary

When resuming an interrupted blob download in retry_download_loop (src/fls/oci/from_oci.rs), the code sends a Range: bytes=<offset>- request and checks that the response status is 206 Partial Content. However, it does not validate the Content-Range response header to confirm the server is resuming from the expected byte offset.

A misbehaving registry or proxy could return 206 with a Content-Range starting from a different offset while sending mismatched data, resulting in a silently corrupted reconstructed blob.

Impact

  • Compressed blobs (gzip, xz, zstd): their built-in checksums would likely surface corruption during decompression — risk is low.
  • Uncompressed blobs (Compression::None, mapped to cat): no checksum validation exists, so data corruption would be silent and the flashed image would be incorrect.

Suggested Fix

After receiving a 206 Partial Content response in retry_download_loop, parse the Content-Range header (format: bytes start-end/total) and verify start == bytes_received. If the header is missing or the start offset does not match, return an error instead of accepting the stream.

References

/cc @mangelajo

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions