LibreKAT/Ocideck

Watch

Fork 0

feat(security): serveer een eigen security.txt vanuit de webbuild (#597) #661

Merged

brenno merged 1 commit from feat/security-txt into main

2026-07-22 17:35:20 +00:00

brenno commented

2026-07-22 17:35:03 +00:00

Owner

De bezorging op security@librekat.nl is door de uitgever getest (2026-07-22). Dat was het expliciet onbevestigde deel van deze issue, en het staat nu vast — ook in SECURITY.md, met datum.

De andere helft zit op de site en niet in deze repo: librekat.nl/.well-known/security.txt wijst naar stichting@ en heeft geen Policy. Daar kan ik niet bij.

Wat hier wél kon

Alles onder web/ wordt naar build/web/ gekopieerd. De app kan dus zijn eigen bestand op de standaardroute serveren. Dat lost librekat.nl niet op, maar wel elke plek waar deze build gehost wordt — en dat is de origin waar iemand die de webversie gebruikt als eerste kijkt.

De twee bestanden bijten elkaar niet: die op de site dekt de stichting, deze dekt deze applicatie, en ze wijzen naar dezelfde mailbox.

De poort

Dit bestand veroudert stil en niemand komt er uit zichzelf langs — dat is precies het soort bestand waar deze repo een test op zet. test/security_txt_test.dart toetst:

het meldadres is hetzelfde als in SECURITY.md (het staat nu op vier plekken; dat is er één te veel om met de hand gelijk te houden);
de verplichte velden Contact en Expires staan erin;
het bestand is niet vervallen;
de vervaldatum staat niet verder dan een jaar vooruit — dat is de controle uitstellen in plaats van hem doen, en RFC 9116 wil het zo.

Alle drie de faalrichtingen geplant en afgegaan.

Dat een vervallen bestand de bouw laat vallen is opzet: een vervallen security.txt leest als "hier is niemand thuis", precies op het moment dat iemand iets te melden heeft. De reparatie is één regel, en de foutmelding zegt welke.

make check groen.

Refs #597

De bezorging op `security@librekat.nl` is door de uitgever getest (2026-07-22). Dat was het expliciet onbevestigde deel van deze issue, en het staat nu vast — ook in `SECURITY.md`, met datum. De andere helft zit op de site en niet in deze repo: `librekat.nl/.well-known/security.txt` wijst naar `stichting@` en heeft geen `Policy`. Daar kan ik niet bij. ## Wat hier wél kon Alles onder `web/` wordt naar `build/web/` gekopieerd. De app kan dus zijn **eigen** bestand op de standaardroute serveren. Dat lost librekat.nl niet op, maar wel elke plek waar deze build gehost wordt — en dat is de origin waar iemand die de webversie gebruikt als eerste kijkt. De twee bestanden bijten elkaar niet: die op de site dekt de stichting, deze dekt deze applicatie, en ze wijzen naar dezelfde mailbox. ## De poort Dit bestand veroudert stil en niemand komt er uit zichzelf langs — dat is precies het soort bestand waar deze repo een test op zet. `test/security_txt_test.dart` toetst: - het meldadres is hetzelfde als in `SECURITY.md` (het staat nu op vier plekken; dat is er één te veel om met de hand gelijk te houden); - de verplichte velden `Contact` en `Expires` staan erin; - het bestand is **niet vervallen**; - de vervaldatum staat niet verder dan een jaar vooruit — dat is de controle uitstellen in plaats van hem doen, en RFC 9116 wil het zo. Alle drie de faalrichtingen geplant en afgegaan. Dat een vervallen bestand de bouw laat vallen is opzet: een vervallen security.txt leest als *"hier is niemand thuis"*, precies op het moment dat iemand iets te melden heeft. De reparatie is één regel, en de foutmelding zegt welke. `make check` groen. Refs #597

brenno added 1 commit

2026-07-22 17:35:03 +00:00

feat(security): serveer een eigen security.txt vanuit de webbuild

CI / Docs links (pull_request) Failing after 19s

Details

CI / Docs links (push) Failing after 23s

Details

CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 26s

Details

CI / Supply-chain (Trivy · advisory) (push) Failing after 28s

Details

CI / Web hardening (pull_request) Failing after 29s

Details

CI / Web hardening (push) Failing after 31s

Details

CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 31s

Details

CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 24s

Details

CI / Test (macos-latest) (push) Has been cancelled

Details

CI / Test (windows-latest) (push) Has been cancelled

Details

CI / Test (macos-latest) (pull_request) Has been cancelled

Details

CI / Test (windows-latest) (pull_request) Has been cancelled

Details

d8c49af316

De bezorging op security@librekat.nl is door de uitgever getest (2026-07-22);
dat was het onbevestigde deel van #597 en het staat nu vast.

De andere helft — de security.txt op librekat.nl wijst naar stichting@ en heeft
geen Policy — zit op de site en niet in deze repo. Wat hier wél kon: alles onder
web/ wordt naar build/web/ gekopieerd, dus de app kan zijn eigen bestand op de
standaardroute serveren. Dat lost librekat.nl niet op, maar wel elke plek waar
deze build draait, en het is de origin waar iemand die de webversie gebruikt als
eerste kijkt.

Er hoort een poort op, want dit bestand veroudert stil en niemand komt hier uit
zichzelf langs. Hij toetst dat het meldadres gelijk is aan SECURITY.md, dat de
verplichte velden er zijn, dat het bestand niet vervallen is, en dat de
vervaldatum niet verder dan een jaar vooruit staat — dat laatste is de controle
uitstellen in plaats van hem doen. Alle drie geplant en afgegaan.

Dat een vervallen bestand de bouw laat vallen is opzet: hij leest als "hier is
niemand thuis", precies wanneer iemand iets te melden heeft, en de reparatie is
één regel.

Refs #597

brenno merged commit f8872a5512 into main

2026-07-22 17:35:20 +00:00

brenno referenced this pull request from a commit

2026-07-22 17:35:21 +00:00

Merge pull request 'feat(security): serveer een eigen security.txt vanuit de webbuild (#597)' (#661) from feat/security-txt into main

brenno referenced this pull request

2026-07-22 17:35:23 +00:00

[Security] security.txt points at a different address than SECURITY.md #597