Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-04 02:04: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
receiving server should check the hashes and signatures on that event.
First the signature is checked. The event is redacted following the
[redaction
algorithm](/client-server-api#redactions), and
the resultant object is checked for a signature from the originating
First the signatures are checked. The event is redacted following the
[redaction algorithm](/client-server-api#redactions), and
the resultant object is checked for signatures from the originating
server, following the algorithm described in [Checking for a
signature](/appendices#checking-for-a-signature). Note that this
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
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
of the received event is base64-decoded, and the two are compared for
equality.