Changeset 0bafe9e in Klonkt for CHANGELOG.nl.md

Timestamp:

08/06/2026 10:49:06 AM (5 weeks ago)

Author:

Claude (agent) <aiclaude@…>

Branches:

main

Children:

d74a461

Parents:

5d0d41d

git-author:

Robin <roboburr@…> (08/06/2026 10:49:05 AM)

git-committer:

Claude (agent) <aiclaude@…> (08/06/2026 10:49:06 AM)

Message:

Niet standaard ondertekenen bij de sleutel-ophaal (regressie van 9561d58)

Robins vraag legde bloot wat ik een uur eerder zelf had verslechterd.
verifyRequest haalt de keyId-URL op VOORDAT er iets geverifieerd is, en die URL
komt uit een header die iedereen mag sturen. Sinds 9561d58 werd dat verzoek
standaard ondertekend als een van onze actors -- dus kon een volslagen onbekende
met één POST boiert een ONDERTEKEND verzoek laten sturen naar een adres van zijn
keuze, met onze identiteit eronder. Dat is hoe een instance op een blocklist
belandt.

fetchActor probeert nu onbetekend eerst en tekent alleen als dat niets bruikbaars
oplevert. Voor een instance met authorized fetch verandert er niets behalve één
extra verzoek; voor alle andere verdwijnt de handtekening weer. Een document dat
onbetekend wél komt maar zonder publicKey telt als mislukt -- voor een
verificatie heb je daar niets aan.

Twee tests erbij die de VOLGORDE vastleggen, want dat is hier de hele zaak: een
open instance krijgt precies één, onbetekend verzoek, en een kaal document leidt
tot een tweede, ondertekende poging.

Wat hiermee NIET is opgelost, en in shaer-afq staat: de ophaal blijft aanroepbaar
door een onbekende, alleen niet meer namens ons. Het smaller maken van de
dereference (alleen bij een inReplyTo die we kennen) en het onthouden van
mislukte pogingen zijn aparte stappen.

Suite 454/454.

Co-Authored-By: Claude Opus 5 <noreply@…>

(No files)