Chunked uploads can silently corrupt slide files (no offset validation / out-of-order chunk handling)
まだ誰も着手していません。
評価
調査の方向性
まず、SlideServer のチャンクアップロードのエントリポイントと、issue に記載された /finish の動作を追跡します。提供されている Python またはブラウザーのシナリオを使って、順序が前後するケースと同時アップロードのケースを再現し、その後、オフセットと一時ファイルがどのように扱われているかを調べます。無効なオフセットによって成功した破損ファイルが生成されず、再開動作と整合性チェックが合意された範囲に一致すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- Python
- スター
- 3
- フォーク
- 23
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
camicroscope/SlideLoader のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
camicroscope/SlideLoader#49 · コメント 4 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
camicroscope/SlideLoader#42 · コメント 1 件 ·
camicroscope/SlideLoader の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
conda-forge/conda-forge-bot#7025 ·
メンテナーはふだん 1 日以内に返信
-
area:ci
難易度 1/5 1時間未満 初心者へのやさしさ 74/100
catincloud-labs/dagster-dex#149 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
home-assistant/core#188424 ·
メンテナーはふだん 1 日以内に返信
-
Review backlog (docs-currency): README 'CI run' link lands on a run whose overall badge is cancelledオープンagent/reviewer needs-kind needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 63/100
projectbluefin/utah#880 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
LSan reports obj_gen leak on post-parse usage() exits (aarch64)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
redis/memtier_benchmark#850 ·
メンテナーはふだん 1 日以内に返信