Chunked uploads can silently corrupt slide files (no offset validation / out-of-order chunk handling)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start by tracing SlideServer’s chunk upload entry point and the /finish behavior described in the issue. Reproduce the out-of-order and concurrent-upload cases using the provided Python or browser scenarios, then inspect how offsets and temporary files are handled. Done means invalid offsets do not produce a successful corrupted file, with resume behavior and integrity checks matching the agreed scope.
Written by the indexing model from the issue text.
Description
Summary
During testing, I discovered that SlideLoader’s chunked upload pipeline can silently produce corrupted slide files when chunks arrive out of order or when the browser sends multiple parallel chunk uploads.
This happens because SlideServer writes chunks purely based on the client-provided offset without validating:
-
whether the chunk order is correct
-
whether the offset matches the current temp file size
-
whether chunks overlap
-
whether the client retried a previous offset
-
whether the full file content matches the original
This results in corrupted slides being saved without any error.
What works
✔ Sequential Python upload
Uploading a large slide (>2GB) using a simple Python script sending sequential chunks works correctly.
✔ Sequential browser upload
A browser-based uploader (using Fetch API) also works when chunks are strictly uploaded one-by-one.
What breaks
❌ Out-of-order chunks
If chunks are intentionally sent in the wrong order (e.g., 0 → 2 → 1 → 3), SlideServer still accepts them and produces a corrupted file.
Example mismatch:
Original SHA256: 01B1513BFB09718D270EC02B75985B0EE32091BA2CB50D286E760BAB9534DDF1
Uploaded SHA256: 2B8E2616B4668452A2A6C6373BC9E490DDA6D4C8F2F1DED9164E6864E7957824
❌ Parallel browser upload
Using a browser uploader that issues chunk uploads concurrently (similar to how Chrome behaves during heavy uploads or retry conditions), uploads also become corrupted.
The server still returns 200 and proceeds to finish, even though the resulting file does not match the original.
To Reproduce
1. Python Out-of-Order Script
Upload a slide using a Python script that intentionally sends chunks in the wrong order.
Chunk order example:
chunk 0 (offset 0)
chunk 2 (offset 1*chunk_size)
chunk 1 (offset 2*chunk_size)
then chunks 3+
SlideServer will:
- accept all chunks
- return 200
- save a corrupted file
2. Browser Aggressive Upload
Create a small browser uploader using Fetch that uploads chunks concurrently (like Chrome does).
With concurrency = 6, I observed:
- out-of-order requests
- overlapping offsets
- retries
- corrupted final file
### Expected Behavior
SlideServer should:
- Reject out-of-order chunks (409 Offset Mismatch)
- Validate offset == current_temp_file_size
- Prevent overlapping writes
- Optionally verify SHA256 at /finish
- Expose correct resume behavior if validation fails
### Actual Behavior
- Out-of-order chunks are written without checking
- Final file is corrupted but server returns success
- No warnings or log messages
- No way for client to detect corruption
Browser concurrency triggers silent corruption
Screenshots
Desktop:
- OS: Windows 11 (64-bit)
- Browser: Google Chrome
- Browser Version: 119.0.6045.200
- Python: Anaconda Python 3.10 (used for running SlideServer and tests)
- SlideLoader setup: Local clone on Windows filesystem (D:\Gsoc\SlideLoader)
Suggested Fix
I can provide a PR including:
- offset validation:
current_size = os.path.getsize(tmppath)
if offset != current_size:
return 409
- per-token write locks
- optional SHA256 integrity check
- improved error responses
Let me know if you’d like a PR
- Dominant language
- Python
- Stars
- 3
- Forks
- 23
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from camicroscope/SlideLoader
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
camicroscope/SlideLoader#49 · 4 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
camicroscope/SlideLoader#42 · 1 comment ·
All issues in camicroscope/SlideLoader
Similar issues
-
SSM GetParameter throttling during concurrent workflow launchesPossibly taken @alexiswl claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
-
[Bug] Dev image build fails: `npm install` in the root Dockerfile runs out of memory (exit 134)Possibly taken @andest01 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
pesu-dev/discord_bot#97 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
gradio-app/gradio#13964 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 93/100
BSData/horus-heresy-3rd-edition#3232 · 1 comment ·
Maintainers usually reply within 1 day