Public share thumbnail probe returns 404 after 30-second wait

kayg commented

2026-09-26 20:36:57 +00:00

Owner

The post-merge adversarial share-options probe could not obtain a public thumbnail for a valid JPEG.

tests/adversarial/attack2.py uploads crates/plugins/files/tests/black.jpg to Audit/Secret photo name.jpg, then polls /api/v1/files/entries?path=Audit for 30 seconds. The probe reported no thumbnail for the shared photo after 30 s. It then got 404 from both view-only public thumbnail sizes (/thumb?s=256 and s=1024), 404 for thumbnail revalidation, and 404 in the password gallery burst. The local server stayed alive.

This run had several concurrent adversarial jobs and had already uploaded many photo fixtures, so thumbnail-worker pressure may be a factor. The test did not see a delayed thumbnail before its wait expired. Please check image-job backpressure and public thumbnail readiness under load, then rerun the share-options section with a low-load server.

The post-merge adversarial `share-options` probe could not obtain a public thumbnail for a valid JPEG. `tests/adversarial/attack2.py` uploads `crates/plugins/files/tests/black.jpg` to `Audit/Secret photo name.jpg`, then polls `/api/v1/files/entries?path=Audit` for 30 seconds. The probe reported `no thumbnail for the shared photo after 30 s`. It then got 404 from both view-only public thumbnail sizes (`/thumb?s=256` and `s=1024`), 404 for thumbnail revalidation, and 404 in the password gallery burst. The local server stayed alive. This run had several concurrent adversarial jobs and had already uploaded many photo fixtures, so thumbnail-worker pressure may be a factor. The test did not see a delayed thumbnail before its wait expired. Please check image-job backpressure and public thumbnail readiness under load, then rerun the share-options section with a low-load server.

kayg commented

2026-09-26 21:40:21 +00:00

Author

Owner

Follow-up evidence from the post-merge adversarial run on 2026-09-26 (dev merge 57894643):

The share setup did not find a thumbnail for Audit/Secret photo name.jpg within 30 seconds.
The public view-only thumbnail at sizes 256 and 1024 returned 404. Thumbnail revalidation returned 404 without an ETag, and the password gallery burst returned 404.
Ten repeated /thumb?s=1024 requests for the view-and-download link also returned 404 before the three-download limit was reached.
The server stayed alive. The HEIF/AVIF upload probe passed, and the restart probe reported 0 findings.

These requests ran while other adversarial jobs shared the host. The 404s are non-SLOW functional findings and reproduce the thumbnail-readiness issue tracked here.

Follow-up evidence from the post-merge adversarial run on 2026-09-26 (dev merge `57894643`): - The share setup did not find a thumbnail for `Audit/Secret photo name.jpg` within 30 seconds. - The public view-only thumbnail at sizes 256 and 1024 returned 404. Thumbnail revalidation returned 404 without an ETag, and the password gallery burst returned 404. - Ten repeated `/thumb?s=1024` requests for the view-and-download link also returned 404 before the three-download limit was reached. - The server stayed alive. The HEIF/AVIF upload probe passed, and the restart probe reported `0 findings`. These requests ran while other adversarial jobs shared the host. The 404s are non-SLOW functional findings and reproduce the thumbnail-readiness issue tracked here.

kayg referenced this issue

2026-09-26 22:10:57 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg commented

2026-09-26 22:16:39 +00:00

Author

Owner

Additional confirmation from the post-merge adversarial pass on 2026-09-27:

The real-server share-options section uploaded the repository JPEG to Audit/Secret photo name.jpg and polled Files entries for 30 seconds. No thumbnail appeared.
Public thumbnail requests at sizes 256 and 1024 returned 404, as did thumbnail revalidation and the password-gallery burst.
The server remained alive. This ran while several other adversarial jobs were active on the shared host, so it does not isolate the cause.

This confirms the existing finding; no Files media change was made in issue #148.

Additional confirmation from the post-merge adversarial pass on 2026-09-27: - The real-server `share-options` section uploaded the repository JPEG to `Audit/Secret photo name.jpg` and polled Files entries for 30 seconds. No thumbnail appeared. - Public thumbnail requests at sizes 256 and 1024 returned 404, as did thumbnail revalidation and the password-gallery burst. - The server remained alive. This ran while several other adversarial jobs were active on the shared host, so it does not isolate the cause. This confirms the existing finding; no Files media change was made in issue #148.

kayg referenced this issue

2026-09-26 22:41:10 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg referenced this issue

2026-09-26 22:42:25 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg referenced this issue

2026-09-27 05:07:36 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg referenced this issue

2026-09-27 05:17:41 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg commented

2026-09-27 06:17:36 +00:00

Author

Owner

Follow-up from the #191 final adversarial round on 6bbe93e9157c9efa85905924139581384f46bc9f.

In tests/adversarial/attack2.py share setup, the valid JPEG thumbnail was not ready within 30 seconds (SLOW); the subsequent public thumbnail requests returned {256: 404, 1024: 404}. The server stayed alive. Other worktree builds and adversarial probes were active on the shared host. The timeout is load-classified; the 404 is recorded as a finding for the existing investigation.

Follow-up from the #191 final adversarial round on `6bbe93e9157c9efa85905924139581384f46bc9f`. In `tests/adversarial/attack2.py` share setup, the valid JPEG thumbnail was not ready within 30 seconds (`SLOW`); the subsequent public thumbnail requests returned `{256: 404, 1024: 404}`. The server stayed alive. Other worktree builds and adversarial probes were active on the shared host. The timeout is load-classified; the 404 is recorded as a finding for the existing investigation.

kayg commented

2026-09-27 06:50:49 +00:00

Author

Owner

Follow-up from the #191 adversarial run after merging dev through c96a24f9298a5f27662ead94ed677aae7304d119.

The tests/adversarial/attack2.py share-options probe again did not produce a valid JPEG thumbnail within 30 seconds (SLOW). Its subsequent public thumbnail requests returned {256: 404, 1024: 404}. The server stayed alive. Other worktree builds were active on the shared host. This repeats the existing public thumbnail finding; the API run exited 1 on this and the non-SLOW Journal storm timeout, while the restart probe reported zero findings.

Follow-up from the #191 adversarial run after merging `dev` through `c96a24f9298a5f27662ead94ed677aae7304d119`. The `tests/adversarial/attack2.py` share-options probe again did not produce a valid JPEG thumbnail within 30 seconds (`SLOW`). Its subsequent public thumbnail requests returned `{256: 404, 1024: 404}`. The server stayed alive. Other worktree builds were active on the shared host. This repeats the existing public thumbnail finding; the API run exited 1 on this and the non-`SLOW` Journal storm timeout, while the restart probe reported zero findings.

kayg referenced this issue

2026-09-27 07:23:42 +00:00

Block actions: hover controls, make-note (→), block reminders with quiet hours, phone capsule bar (DESIGN §42) #191

kayg referenced this issue

2026-09-27 07:39:31 +00:00

Search palette grows up and down from the centre; hidden (dot) entries never in results #178

kayg commented

2026-09-27 07:54:25 +00:00

Author

Owner

Follow-up from the post-merge adversarial round at e643bf7e:

The runner staged the production media sandbox and passed its real JPEG-to-WebP self-check.
The full share-options section then completed without a thumbnail finding. This includes the 256 px and 1024 px public thumbnail checks that returned 404 before the runner had the sandbox.
The public share finding did not reproduce with the local media runtime enabled. The run did not exercise the packaged container or o2.
hostile_bytes.mjs skipped its 1x1 GIF thumbnail check after 10 seconds; it did not report that as a finding. The round had concurrent servers on the host.

This evidence points to the local adversarial runtime setup as the cause of the earlier 404. I am leaving the issue open for packaged-runtime verification.

Follow-up from the post-merge adversarial round at `e643bf7e`: - The runner staged the production media sandbox and passed its real JPEG-to-WebP self-check. - The full `share-options` section then completed without a thumbnail finding. This includes the 256 px and 1024 px public thumbnail checks that returned 404 before the runner had the sandbox. - The public share finding did not reproduce with the local media runtime enabled. The run did not exercise the packaged container or o2. - `hostile_bytes.mjs` skipped its 1x1 GIF thumbnail check after 10 seconds; it did not report that as a finding. The round had concurrent servers on the host. This evidence points to the local adversarial runtime setup as the cause of the earlier 404. I am leaving the issue open for packaged-runtime verification.

kayg commented

2026-09-27 08:28:05 +00:00

Author

Owner

More sandbox evidence from the menu-icons verification at e643bf7e:

The focused Files fixture run with target/e2e-media-runtime on PATH found the vips probe, then failed on the first JPEG: thumbnail 256 for photo.jpg is missing (failed=true): entry not found (3.09 s). It skipped only the video fixture because sandboxed ffmpeg was unavailable.
A diagnostic rerun captured bwrap: Creating new namespace failed: Resource temporarily unavailable from the first vips-version probe. The test then reported ok in 0.04 s because its current “sandbox unavailable” guard returns early; that run did not exercise thumbnails.
A direct sandboxed vipsheader command and the runner's JPEG-to-WebP self-check worked. The post-merge real-server share-options section also emitted no public-thumbnail finding.

The local thumbnail result is inconsistent under concurrent host load. The successful ok above is an early return, not a passing media fixture. I am leaving this issue open for a clean, media-enabled rerun; no Files behavior change was made in this menu job.

More sandbox evidence from the menu-icons verification at `e643bf7e`: - The focused Files fixture run with `target/e2e-media-runtime` on `PATH` found the vips probe, then failed on the first JPEG: `thumbnail 256 for photo.jpg is missing (failed=true): entry not found` (3.09 s). It skipped only the video fixture because sandboxed ffmpeg was unavailable. - A diagnostic rerun captured `bwrap: Creating new namespace failed: Resource temporarily unavailable` from the first vips-version probe. The test then reported `ok` in 0.04 s because its current “sandbox unavailable” guard returns early; that run did not exercise thumbnails. - A direct sandboxed `vipsheader` command and the runner's JPEG-to-WebP self-check worked. The post-merge real-server `share-options` section also emitted no public-thumbnail finding. The local thumbnail result is inconsistent under concurrent host load. The successful `ok` above is an early return, not a passing media fixture. I am leaving this issue open for a clean, media-enabled rerun; no Files behavior change was made in this menu job.

kayg commented

2026-09-27 10:57:35 +00:00

Author

Owner

The later post-merge adversarial round in CSP issue #118 observed that the share thumbnail was still unavailable at the probe's 10-second wait. That probe skipped the thumbnail header check at this deadline; it did not produce a new HTTP failure. The earlier 30-second wait and dependent 404 responses in this issue remain the direct failure evidence.

kayg commented

2026-09-27 12:22:19 +00:00

Author

Owner

Post-merge media adversarial probe at c2ff7b40 found no generated share thumbnail within its 10-second wait, so it skipped the header check. This is shorter than the existing 30-second reproduction on this issue; the media worker was also busy or unavailable during the run.

Post-merge media adversarial probe at c2ff7b40 found no generated share thumbnail within its 10-second wait, so it skipped the header check. This is shorter than the existing 30-second reproduction on this issue; the media worker was also busy or unavailable during the run.

kayg referenced this issue

2026-09-27 15:40:20 +00:00

Security: enforce the SPA shell Content-Security-Policy (now Report-Only) #118

kayg referenced this issue

2026-10-03 12:56:40 +00:00

Issue hygiene sweep 2026-10-03 #1008

Rows
Columns

Public share thumbnail probe returns 404 after 30-second wait #213