source: Klonkt/src/services/ActivityPubService.js@ 5296349

Doorgestuurde activiteiten alsnog verifiëren bij de bron (shaer-s8k)

De inbox eiste dat een activiteit was ondertekend door de actor die hij claimde
te zijn. Bij DOORSTUREN klopt dat niet: reageert iemand in een thread, dan stuurt
de server van de oorspronkelijke poster die reactie door en ondertekent met zijn
EIGEN sleutel. Op boiert.eu leverde dat tientallen geweigerde Creates op van
echte accounts -- reacties die niet aankwamen, zonder dat iemand een fout zag.

Mastodon lost dit op met een LD-Signature over de payload. Dat vraagt
JSON-LD-canonicalisatie; dit doet het lichter en strenger: bij een mismatch
geloven we de bezorgde inhoud NIET en halen we het object op bij de bron.

Vier voorwaarden, en geen ervan is optioneel:

• alleen Create en Update. Een doorgestuurde Delete is niet te dereferencen (het object is weg) en blijft geweigerd.
• de host van de object-id moet die van de geclaimde actor zijn. Zonder dit anker wijst een doorsturer je naar een host die hij zelf beheert, waar attributedTo alles kan beweren.
• het OPGEHAALDE object wordt gebruikt, niet de bezorgde payload. Anders levert een doorsturer een echt id met verdraaide inhoud.
• mislukt het ophalen, wijkt het id af, of schrijft de bron het object niet toe aan de geclaimde actor, dan blijft het een weigering.

Een ongetekende activiteit wordt niet gedereferenced: zonder bewijs van wie het
bezorgde is er niets om op te bouwen. Beide fetch-paden lopen door safeFetch met
zijn SSRF-preflight.

Ook de logregel gesplitst. "(unsigned/invalid)" betekende drie dingen tegelijk;
het onderscheidt nu 'no signature', 'signature present, unverifiable' (meestal
een opgeheven account waarvan de sleutel weg is -- dat verklaart het gros van de
Delete-regels) en 'signer mismatch'.

Acht tests, waarvan zes weiger-gevallen: andere host, verkeerde attributedTo,
bron onbereikbaar, afwijkend id, doorgestuurde Delete, en ongetekend. Die
gebruiken IP-literals uit TEST-NET-3, want safeFetch doet dan geen DNS-lookup en
de test blijft offline.

Suite 449/449.

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