fix: update retry test expectations and validate Content-Range on resume

Update TestPullMaxRetriesExhausted to expect 5 HTTP calls (1 initial +
4 retries) and the correct error message now that Pull uses maxRetries=4.

Also address a bug-risk review comment in rangeTransport.RoundTrip: add
Content-Range header validation so we only record a range request as
successful when the server returns 206 with a start offset matching the
requested offset. This guards against misbehaving servers that return
206 with a different range, which would cause WriteBlob to append at
the wrong position and corrupt the blob.

Author: ericcurtin

cmd/cli/desktop/desktop_test.go

@@ -191,13 +191,13 @@ func TestPullMaxRetriesExhausted(t *testing.T) {
 	mockContext := NewContextForMock(mockClient)
 	client := New(mockContext)
 
-	// All 4 attempts (1 initial + 3 retries) fail with network error
-	mockClient.EXPECT().Do(gomock.Any()).Return(nil, io.EOF).Times(4)
+	// All 5 attempts (1 initial + 4 retries) fail with network error
+	mockClient.EXPECT().Do(gomock.Any()).Return(nil, io.EOF).Times(5)
 
 	printer := NewSimplePrinter(func(s string) {})
 	_, _, err := client.Pull(modelName, printer)
 	assert.Error(t, err)
-	assert.Contains(t, err.Error(), "download failed after 3 retries")
+	assert.Contains(t, err.Error(), "download failed after 4 retries")
 }
 
 func TestPushRetryOnNetworkError(t *testing.T) {

pkg/distribution/oci/remote/remote.go

@@ -198,18 +198,47 @@ func (t *rangeTransport) RoundTrip(req *http.Request) (*http.Response, error) {
 	}
 
 	// If we requested a Range, record success only when the server honoured it
-	// with 206 Partial Content. A 200 response means the server ignored the Range
-	// header and is sending the full file from byte 0; appending that stream to
-	// the existing partial file would produce a corrupt blob.
+	// with 206 Partial Content and a matching Content-Range start offset. A 200
+	// response means the server ignored the Range header and is sending the full
+	// file from byte 0; appending that stream to the existing partial file would
+	// produce a corrupt blob. We also validate the Content-Range start offset to
+	// guard against a misbehaving server that returns 206 with a different range.
 	if requestedOffset > 0 && resp.StatusCode == http.StatusPartialContent {
-		if rs := GetRangeSuccess(req.Context()); rs != nil {
-			rs.Add(digest, requestedOffset)
+		if rangeStartMatchesOffset(resp.Header.Get("Content-Range"), requestedOffset) {
+			if rs := GetRangeSuccess(req.Context()); rs != nil {
+				rs.Add(digest, requestedOffset)
+			}
 		}
 	}
 
 	return resp, nil
 }
 
+// rangeStartMatchesOffset parses the Content-Range response header and reports
+// whether its start byte equals the given offset. The format is defined by
+// RFC 9110: "bytes START-END/TOTAL" (TOTAL may be "*"). We fail closed: if the
+// header is absent or cannot be parsed we return false so that the caller does
+// not treat an ambiguous response as a successful range request.
+func rangeStartMatchesOffset(contentRange string, offset int64) bool {
+	if contentRange == "" {
+		return false
+	}
+	// Trim the unit prefix "bytes " and split on "-"
+	after, ok := strings.CutPrefix(contentRange, "bytes ")
+	if !ok {
+		return false
+	}
+	dashIdx := strings.Index(after, "-")
+	if dashIdx < 0 {
+		return false
+	}
+	var start int64
+	if _, err := fmt.Sscanf(after[:dashIdx], "%d", &start); err != nil {
+		return false
+	}
+	return start == offset
+}
+
 // extractDigestAndOffset extracts the blob digest from the request URL and returns
 // the corresponding resume offset if one exists.
 func (t *rangeTransport) extractDigestAndOffset(req *http.Request, offsets map[string]int64) (string, int64) {