Merge 795cc3fce9 into 156d1b878a

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

changelogs/client_server/newsfragments/2348.clarification

@@ -0,0 +1 @@
+Fix ordering of common error codes.

changelogs/server_server/newsfragments/2341.clarification

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

content/client-server-api/_index.md

@@ -126,6 +126,25 @@ state (e.g.: sending messages, account data, etc) and not routes which
 only read state (e.g.: [`/sync`](#get_matrixclientv3sync),
 [`/user/{userId}/account_data/{type}`](#get_matrixclientv3useruseridaccount_datatype), etc).
 
+`M_UNKNOWN`
+: An unknown error has occurred.
+
+`M_UNKNOWN_DEVICE`
+: {{% added-in v="1.17" %}} The device ID supplied by the application service does
+not belong to the user ID during [identity assertion](/application-service-api/#identity-assertion).
+
+`M_UNKNOWN_TOKEN`
+: The access or refresh token specified was not recognised.
+
+: An additional response parameter, `soft_logout`, might be present on the
+response for 401 HTTP status codes. See [the soft logout
+section](#soft-logout) for more information.
+
+`M_UNRECOGNIZED`
+: The server did not understand the request. This is expected to be returned with
+a 404 HTTP status code if the endpoint is not implemented or a 405 HTTP status
+code if the endpoint is implemented, but the incorrect HTTP method is used.
+
 `M_USER_LIMIT_EXCEEDED`
 : {{% added-in v="1.18" %}} The request cannot be completed because the user has
 exceeded (or the request would cause them to exceed) a limit associated with
@@ -157,25 +176,6 @@ limit is a hard limit that cannot be increased.
   }
   ```
 
-`M_UNKNOWN`
-: An unknown error has occurred.
-
-`M_UNKNOWN_DEVICE`
-: {{% added-in v="1.17" %}} The device ID supplied by the application service does
-not belong to the user ID during [identity assertion](/application-service-api/#identity-assertion).
-
-`M_UNKNOWN_TOKEN`
-: The access or refresh token specified was not recognised.
-
-: An additional response parameter, `soft_logout`, might be present on the
-response for 401 HTTP status codes. See [the soft logout
-section](#soft-logout) for more information.
-
-`M_UNRECOGNIZED`
-: The server did not understand the request. This is expected to be returned with
-a 404 HTTP status code if the endpoint is not implemented or a 405 HTTP status
-code if the endpoint is implemented, but the incorrect HTTP method is used.
-
 `M_USER_LOCKED`
 : The account has been [locked](#account-locking) and cannot be used at this time.
 

content/server-server-api.md

@@ -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 unexpired keys from the originating server(s) 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.