.DS_Store staat live op ocideck.librekat.nl en zit in de gepubliceerde SHA256SUMS #1888

New issue

Closed

opened 2026-08-31 13:35:44 +00:00 by brenno · 0 comments

brenno commented

2026-08-31 13:35:44 +00:00

Owner

https://ocideck.librekat.nl/.DS_Store geeft HTTP 200, 6148 bytes.

$ curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://ocideck.librekat.nl/.DS_Store
200 6148

Het staat ook in de gepubliceerde checksumlijst — het is dus geen restant op de
host maar zat in de bundel die de deur uit ging:

$ curl -s https://ocideck.librekat.nl/SHA256SUMS | head -1
e8001a34263b8601cbd1942aa6bbc198f8fef83cbc2c248972601c9c53df6bb6  .DS_Store

Een .DS_Store is Finder-metadata en bevat de bestands- en mapnamen van de map
waar hij uit komt. Op een publieke webhost is dat een standaardbevinding: het
geeft een directory-listing weg van de buildmap zonder dat er een listing
aanstaat. Laag risico hier — het is een buildmap, geen documentwortel — maar het
hoort er niet en het is triviaal te voorkomen.

Waarom geen poort hem ving

tool/pack_web_release.dart heeft precies hiervoor een lijst:

/// Bestanden die Flutter in `build/web` achterlaat maar die er niet horen.
const List<String> nietUitleveren = ['.last_build_id'];

.DS_Store staat er niet op. .gitignore vangt hem wel (hij komt de repo niet
in), maar de bundel wordt uit build/web gebouwd en die map is niet gitignored
gebied — hij krijgt een .DS_Store zodra iemand hem in Finder opent.

Ook gemist door:

make check-web (webharding) — kijkt naar headers en CSP, niet naar wat er in
de bundel zit;
de DAST-slag in make check-release — een ZAP-baseline spidert niet naar
verborgen bestanden.

Het breekt ook de reproduceerbaarheid

De doc-comment bij .last_build_id legt uit waarom dat bestand eruit moet: het
verschilt per bouwmachine, dus wie zelf bouwt kan de gepubliceerde digest nooit
reproduceren. .DS_Store heeft exact die eigenschap — hij hangt af van of
iemand de map in Finder heeft geopend. Zolang hij meegaat in SHA256SUMS is de
gepubliceerde digest van de webbundel niet reproduceerbaar, en dat raakt het
werk uit #1027/#1033.

Voorstel

.DS_Store (en breder: elk bestand dat met . begint en niet in
releaseArtefacten staat) op nietUitleveren in
tool/pack_web_release.dart, met een test die het vastlegt.
Het bestand van de host halen.
Overwegen of pack_web_release.dart --check niet standaard moet klagen over
onverwachte bestanden in de bundel in plaats van alleen over ontbrekende —
een allowlist in plaats van een denylist sluit de hele klasse.

Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026.

`https://ocideck.librekat.nl/.DS_Store` geeft **HTTP 200, 6148 bytes**. ``` $ curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://ocideck.librekat.nl/.DS_Store 200 6148 ``` Het staat ook in de gepubliceerde checksumlijst — het is dus geen restant op de host maar zat in de bundel die de deur uit ging: ``` $ curl -s https://ocideck.librekat.nl/SHA256SUMS | head -1 e8001a34263b8601cbd1942aa6bbc198f8fef83cbc2c248972601c9c53df6bb6 .DS_Store ``` Een `.DS_Store` is Finder-metadata en bevat de bestands- en mapnamen van de map waar hij uit komt. Op een publieke webhost is dat een standaardbevinding: het geeft een directory-listing weg van de buildmap zonder dat er een listing aanstaat. Laag risico hier — het is een buildmap, geen documentwortel — maar het hoort er niet en het is triviaal te voorkomen. ## Waarom geen poort hem ving `tool/pack_web_release.dart` heeft precies hiervoor een lijst: ```dart /// Bestanden die Flutter in `build/web` achterlaat maar die er niet horen. const List<String> nietUitleveren = ['.last_build_id']; ``` `.DS_Store` staat er niet op. `.gitignore` vangt hem wel (hij komt de repo niet in), maar de bundel wordt uit `build/web` gebouwd en die map is niet gitignored gebied — hij krijgt een `.DS_Store` zodra iemand hem in Finder opent. Ook gemist door: - `make check-web` (webharding) — kijkt naar headers en CSP, niet naar wat er in de bundel zit; - de DAST-slag in `make check-release` — een ZAP-baseline spidert niet naar verborgen bestanden. ## Het breekt ook de reproduceerbaarheid De doc-comment bij `.last_build_id` legt uit waarom dat bestand eruit moet: het verschilt per bouwmachine, dus wie zelf bouwt kan de gepubliceerde digest nooit reproduceren. `.DS_Store` heeft exact die eigenschap — hij hangt af van of iemand de map in Finder heeft geopend. Zolang hij meegaat in `SHA256SUMS` is de gepubliceerde digest van de webbundel **niet reproduceerbaar**, en dat raakt het werk uit #1027/#1033. ## Voorstel 1. `.DS_Store` (en breder: elk bestand dat met `.` begint en niet in `releaseArtefacten` staat) op `nietUitleveren` in `tool/pack_web_release.dart`, met een test die het vastlegt. 2. Het bestand van de host halen. 3. Overwegen of `pack_web_release.dart --check` niet standaard moet klagen over onverwachte bestanden in de bundel in plaats van alleen over ontbrekende — een allowlist in plaats van een denylist sluit de hele klasse. _Gevonden bij een kritische review van het kwaliteitsbewakingssysteem, 31-08-2026._

brenno added the

security

label

2026-08-31 13:35:44 +00:00

brenno added the

in-progress

label

2026-08-31 15:47:19 +00:00

brenno referenced this issue from a commit

2026-08-31 15:57:06 +00:00

fix(security): .DS_Store uit webbundel, attestatie op waarheid, branch-protection (#1888, #1889, #1891)

brenno referenced this issue