@Profpatsch yeah, that's the question I'm asking. Is there any risk in accepting a message that old?
I don't think there is - but I wanted to check with wiser minds.

@Edent personally I think it's healthy for the network to accept these, but @silverpill knows best

@Profpatsch @Edent

An HTTP signature proves that an activity exists on the originating server - it's substitute for fetching activity by its ID. The originating server has full control over the activity JSON and the request headers, so the date of publishing doesn't matter.

What may matter is the date when the signature itself was created. If you receive a request signed several days ago, that might indicate a replay attack... Or a broken clock on the sender side.

@evan Thanks - I had mine at two minutes.
I'm starting to see more exceeding 10 minutes.
I wonder what the actual risk is of accepting something with that long a delay?

@Edent @silverpill @Profpatsch yeah, the Activity could have been in a low priority queue. Either way this type of activity isnt always fetchable so I’d accept!

A weird #ActivityPub message from #Frendica.

Signed on 2026-09-01
Published on 2026-03-02

That's a skew of six months! The message type is "Undo" - so they're undoing a like they sent in March.

Is there *really* a worry about accepting requests like this? Given the message has been signed, what risk is there to replay attacks?

Another Mastodon / ActivityPub signature question.

Alice reposts Bob.
Bob updates their post.
Alice's instance syndicates that update to her followers.

The message Alice's instance sends has an Actor of Bob. But the headers are signed by Alice. So the signature doesn't match the actor.

Which means Bob's embedded RsaSignature2017 *also* needs to be checked.

Security - Mastodon documentation

Public key cryptography and supported signature schemes over HTTP and JSON-LD.

(docs.joinmastodon.org)

But that doesn't mean I can skip checking Alice's signature, right?

The documentation says:

> Strip type, id, and signatureValue from the signature, leaving only signature[creator] and signature[created].
> Base64-decode the signatureValue and verify it against the public key in signature[creator].

But it doesn't say *what* to validate the signature against!

Is it a JSON document just containing creator and created? Or is it something else?

@Edent oh.... it's against some wild RDF thingy that you obtain by putting the JSON document through some JSON-LD processing algorithms. My memory is fuzzy because I implemented that from scratch way back in 2019, but here's my known working implementation if that helps:
https://github.com/grishka/Smithereen/blob/master/src/main/java/smithereen/jsonld/LinkedDataSignatures.java

Smithereen/src/main/java/smithereen/jsonld/LinkedDataSignatures.java at master · grishka/Smithereen

Federated, ActivityPub-compatible social network server with friends, walls, and groups. - Smithereen/src/main/java/smithereen/jsonld/LinkedDataSignatures.java at master · grishka/Smithereen

GitHub (github.com)

@Edent oh.... it's against some wild RDF thingy that you obtain by putting the JSON document through some JSON-LD processing algorithms. My memory is fuzzy because I implemented that from scratch way back in 2019, but here's my known working implementation if that helps:
https://github.com/grishka/Smithereen/blob/master/src/main/java/smithereen/jsonld/LinkedDataSignatures.java

Smithereen/src/main/java/smithereen/jsonld/LinkedDataSignatures.java at master · grishka/Smithereen

Federated, ActivityPub-compatible social network server with friends, walls, and groups. - Smithereen/src/main/java/smithereen/jsonld/LinkedDataSignatures.java at master · grishka/Smithereen

GitHub (github.com)