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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions