Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-07 03:44:10 +02:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge d3fcc122eb into 9c014a9045

Browse source
This commit is contained in:
timedout 2026-03-31 23:21:19 +01:00 committed by GitHub
parent 9c014a9045 d3fcc122eb
commit 6a0765a2e4
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 11 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelogs/server_server/newsfragments/2341.clarification Normal file
View file

@ -0,0 +1 @@
Clarify how multiple signatures should be handled during signature verification. Contributed by @nexy7574.

15
content/server-server-api.md
View file

@ -1484,10 +1484,9 @@ the Policy Server for a signature too.
When a server receives an event over federation from another server, the When a server receives an event over federation from another server, the
receiving server should check the hashes and signatures on that event. receiving server should check the hashes and signatures on that event.
First the signature is checked. The event is redacted following the First the signatures are checked. The event is redacted following the
[redaction [redaction algorithm](/client-server-api#redactions), and
algorithm](/client-server-api#redactions), and the resultant object is checked for signatures from the originating
the resultant object is checked for a signature from the originating
server, following the algorithm described in [Checking for a server, following the algorithm described in [Checking for a
signature](/appendices#checking-for-a-signature). Note that this signature](/appendices#checking-for-a-signature). Note that this
step should succeed whether we have been sent the full event or a step should succeed whether we have been sent the full event or a
@ -1503,7 +1502,13 @@ The signatures expected on an event are:
Other room versions do not track the `event_id` over federation and Other room versions do not track the `event_id` over federation and
therefore do not need a signature from those servers. therefore do not need a signature from those servers.
If the signature is found to be valid, the expected content hash is Only signatures from known server keys are validated here, any unknown keys are ignored.
In particular, the [policy server key](#validating-policy-server-signatures) is not
expected to be published and therefore should be skipped at this stage.
Additionally, any keys that are known to have expired prior to the event's
`origin_server_ts` are ignored.
If all signatures from known keys are found to be valid, the expected content hash is
calculated as described below. The content hash in the `hashes` property calculated as described below. The content hash in the `hashes` property
of the received event is base64-decoded, and the two are compared for of the received event is base64-decoded, and the two are compared for
equality. equality.