* fix: honor SSE-C chunk offsets in decryption for large chunked uploads
Fixes issue #8215 where SSE-C decryption for large objects could corrupt
data by ignoring per-chunk PartOffset values.
Changes:
- Add TestSSECLargeObjectChunkReassembly unit test to verify correct
decryption of 19MB object split into 8MB chunks using PartOffset
- Update decryptSSECChunkView and createMultipartSSECDecryptedReaderDirect
to extract PartOffset from SSE-C metadata and pass to
CreateSSECDecryptedReaderWithOffset for offset-aware decryption
- Fix createCTRStreamWithOffset to use calculateIVWithOffset for proper
block-aligned counter advancement, matching SSE-KMS/S3 behavior
- Update comments to clarify SSE-C IV handling uses per-chunk offsets
(unlike base IV approach used by KMS/S3)
All tests pass: go test ./weed/s3api ✓
* fix: close chunkReader on error paths in createMultipartSSECDecryptedReader
Address resource leak issue reported in PR #8216: ensure chunkReader is
properly closed before returning on all error paths, including:
- DeserializeSSECMetadata failures
- IV decoding errors
- Invalid PartOffset values
- SSE-C reader creation failures
- Missing per-chunk metadata
This prevents leaking network connections and file handles during
SSE-C multipart decryption error scenarios.
* docs: clarify SSE-C IV handling in decryptSSECChunkView comment
Replace misleading warning 'Do NOT call calculateIVWithOffset' with
accurate explanation that:
- CreateSSECDecryptedReaderWithOffset internally uses calculateIVWithOffset
to advance the CTR counter to reach PartOffset
- calculateIVWithOffset is applied only to the per-part IV, NOT to derive
a global base IV for all parts
- This differs fundamentally from SSE-KMS/SSE-S3 which use base IV +
calculateIVWithOffset(ChunkOffset)
This clarifies the IV advancement mechanism while contrasting it with
the base IV approach used by other encryption schemes.
c2bfd7b524