Merge pull request #2081 from matrix-org/travis/1.0/pdu-signatures
Clarify which servers are supposed to sign events
This commit is contained in:
commit
6a4a6db1bd
2 changed files with 12 additions and 3 deletions
|
@ -0,0 +1 @@
|
|||
Clarify which servers are supposed to sign events.
|
|
@ -421,9 +421,8 @@ must ensure that the event:
|
|||
Further details of these checks, and how to handle failures, are described
|
||||
below.
|
||||
|
||||
.. TODO:
|
||||
Flesh this out a bit more, and probably change the doc to group the various
|
||||
checks in one place, rather than have them spread out.
|
||||
The `Signing Events <#signing-events>`_ section has more information on which hashes
|
||||
and signatures are expected on events, and how to calculate them.
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
as described below. The content hash in the ``hashes`` property of the received
|
||||
event is base64-decoded, and the two are compared for equality.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue