wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #2081 from matrix-org/travis/1.0/pdu-signatures

Browse source 
Clarify which servers are supposed to sign events
This commit is contained in:
Travis Ralston 2019-06-07 08:56:14 -06:00 • committed by GitHub
commit 6a4a6db1bd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 12 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -0,0 +1 @@
Clarify which servers are supposed to sign events.

14
specification/server_server_api.rst
View file

@ -421,9 +421,8 @@ must ensure that the event:
Further details of these checks, and how to handle failures, are described Further details of these checks, and how to handle failures, are described
below. below.
.. TODO: The `Signing Events <#signing-events>`_ section has more information on which hashes
Flesh this out a bit more, and probably change the doc to group the various and signatures are expected on events, and how to calculate them.
checks in one place, rather than have them spread out.
Definitions Definitions
@ -1099,6 +1098,15 @@ originating server, following the algorithm described in `Checking for a signatu
Note that this step should succeed whether we have been sent the full event or Note that this step should succeed whether we have been sent the full event or
a redacted copy. a redacted copy.
The signatures expected on an event are:
* The ``sender``'s server, unless the invite was created as a result of 3rd party invite.
The sender must already match the 3rd party invite, and the server which actually
sends the event may be a different server.
* For room versions 1 and 2, the server which created the ``event_id``. 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 calculated If the signature is found to be valid, the expected content hash is calculated
as described below. The content hash in the ``hashes`` property of the received as described below. The content hash in the ``hashes`` property of the received
event is base64-decoded, and the two are compared for equality. event is base64-decoded, and the two are compared for equality.