From b47de28da543f165795812afa366cacd64211a01 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 24 Jan 2020 00:40:33 +0100 Subject: [PATCH 01/79] MSC2422: Allow color on font tag Signed-off-by: Nicolas Werner --- .../2422-allow-color-attribute-on-font-tag.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 proposals/2422-allow-color-attribute-on-font-tag.md diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md new file mode 100644 index 00000000..4287a696 --- /dev/null +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -0,0 +1,38 @@ +# MSC2422: Allow `color` as attribute for `` in messages + +Currently the spec requires you to use `data-mx-color` instead of the standard +`color` html attribute for the `` tag. This is probably done to make it +consistent with ``, where you may not want to allow a generic style tag for. + +On the other hand the /rainbow command on almost every client just uses the +`color` attribute of the `` tag. While some clients support +`data-mx-color` (i.e. Riot Web), most clients don't. Most clients support +rendering `color` however. + +It would probably be for the best to allow or even prefer `color` on the +`` tag. + +## Proposal + +Add the `color` attribute to the allowed attributes of `` in section +13.2.1.7. Allow only hexcodes as allowed value for this attribute for now. + +## Potential issues + +- We now have a redundant attribute in the spec. While it matches, what the + clients currently do, it may be better to fix each client instead. +- Clients may not sanitize the color attribute and will let other color values + through, increasing compatibility issues again. +- Clients may never support the data-mx-* attributes now. +- Old messages could loose their color +- This proposal doesn't touch span at all, maybe it should? + +## Alternatives + +- fix the clients +- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving + us just with `color` for `` +- Add a section to tell the clients to prefer `color` over `mx-data-color` +- Spec an entirely different format for messages (that would probably not make + this proposal obsolete) + From 6bd4b3c08a7a5137700c8fbf76008b27de92efe0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 10 Feb 2020 20:29:38 +0000 Subject: [PATCH 02/79] MSC: Updated semantics for publishing room aliases --- proposals/2432-revised-alias-publishing.md | 225 +++++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 proposals/2432-revised-alias-publishing.md diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md new file mode 100644 index 00000000..8ef08f7d --- /dev/null +++ b/proposals/2432-revised-alias-publishing.md @@ -0,0 +1,225 @@ +# MSC2432: Updated semantics for publishing room aliases + +This MSC offers an alternative to [MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260). + +## Background + +The [`m.room.aliases`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-aliases) +state event exists to list the available aliases for a given room. This serves +two purposes: + + * It allows existing members of the room to discover alternative aliases, + which may be useful for them to pass this knowledge on to others trying to + join. + + * Secondarily, it helps to educate users about how Matrix works by + illustrating multiple aliases per room and giving a perception of the size + of the network. + +However, it has problems: + + * Any user in the entire ecosystem can create aliases for rooms, which are + then unilaterally added to `m.room.aliases`, and room admins are unable to + remove them. This is an abuse + vector (https://github.com/matrix-org/matrix-doc/issues/625). + + * For various reasons, the `m.room.aliases` event tends to get out of sync + with the actual aliases (https://github.com/matrix-org/matrix-doc/issues/2262). + +## Proposal + +We propose that that room moderators should be able to manually curate a list +of "official" aliases for their room, instead of matrix servers automatically +publishing lists of all room aliases into the room state. No particular +guarantees are offered that this alias list is entirely accurate: it becomes +room moderators' responsibilty to keep it so. + +Meanwhile, the aliases that map to a given room on a given server become +the ultimate responsibility of the administrators of that server. We give them +tools to inspect the alias list and clean it up when necessary, in addition to +the current tools which allow restriction of who can create aliases in the +first place. + +A detailed list of proposed modifications to the Matrix spec follows: + + * `m.room.aliases` loses any special meaning within the spec. In particular: + + * Clients should no longer format it specially in room timelines. + + * Clients and servers should no longer consider `m.room.aliases` when + [calculating the display name for a + room](https://matrix.org/docs/spec/client_server/r0.6.0#calculating-the-display-name-for-a-room). + + (Note: servers follow the room display-name algorithm when calculating + room names for certain types of push notification.) + + * A future room version will remove the special [authorization +rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and +[redaction rules](https://matrix.org/docs/spec/client_server/r0.6.0#redactions). + + * [`m.room.canonical_alias`](https://matrix.org/docs/spec/client_server/r0.6.0#m-room-canonical-alias) + is extended to include a new `alt_aliases` property. This, if present, + should be a list of alternative aliases for the room. An example event might + look like: + + ```json + { + "content": { + "alias": "#somewhere:localhost", + "alt_aliases": [ + "#somewhere:overthere.com", + "#somewhereelse:example.com" + ] + }, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "state_key": "", + "type": "m.room.canonical_alias" + } + ``` + + It is valid for `alt_aliases` to be non-empty even if `alias` is absent or + empty. This means that no alias has been picked out as the 'main' alias. + + (Note: although the spec currently claims that `alias` is mandatory, Synapse + generates `m.room.canonical` alias events with no `alias` property when the + main alias is deleted. This change would legitimise that behaviour.) + + (For clarity: it is not proposed that the `alt_aliases` be considered when + calculating the displayname for a room.) + + * [`PUT /_matrix/client/r0/rooms/{roomId}/state/{eventType}/{stateKey}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-rooms-roomid-state-eventtype-statekey) + is extended to recommend that servers validate any *new* aliases added to + `m.room.canonical_alias` by checking that it is a valid alias according to + the [syntax](https://matrix.org/docs/spec/appendices#room-aliases), and by + looking up the alias and and that it corresponds to the expected room ID. + + (Note: Synapse currently implements this check on the main alias, though + this is unspecced.) + + (TODO: what error code should be returned if the alias is invalid, or if it + points to the wrong room?) + + * Currently, [`PUT /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-room-roomalias) + attempts to send updated `m.room.aliases` events on the caller's + behalf. (This is implemented in Synapse but does not appear to be explicitly + specced.) This functionality should be removed. + + * Currently, [`DELETE /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#delete-matrix-client-r0-directory-room-roomalias), + attempts to send updated `m.room.aliases` and/or `m.room.canonical_alias` + events on the caller's behalf, removing any aliases which have been + deleted. (Again, this is implemented in Synapse but does not appear to be + explicitly specced.) The `m.room.aliases` functionality should be removed, + and the `m.room.canonical_alias` functionality should be extended to cover + `alt_aliases`. As today, no error occurs if the caller does not have + permission to send such an event. + + * A new api endpoint, `GET /_matrix/client/r0/rooms/{roomId}/aliases` is + added, which returns the list of aliases currently defined on the local + server for the given room. The response looks like: + + ```json + { + "aliases": [ + "#somewhere:example.com", + "#somewhereelse:example.com", + "#special_alias:example.com" + ] + } + ``` + + This API can be called by any current member of the room (calls from other + users result in `M_FORBIDDEN`). + + TODO: should this be tied in with `history_visibilty` to allow peeking from + non-members? On the one hand that feels like pointless clutter; on the other + it feels like it makes it more consistent with peekable rooms. + +Various APIs are currently subject to implementation-defined access +restrictions. No change to the specification is changed in this regard +(implementations will continue to be free to impose their own +restrictions). Nevertheless as part of this MSC it is useful to consider some +proposed changes to Synapse's implementation: + + * No change: `PUT /_matrix/client/r0/directory/room/{roomAlias}`: Synapse + only allows access to current members of the room, and also exposes some + configuration options which allow restriction of which users are allowed to + create aliases in general. + + * `DELETE /_matrix/client/r0/directory/room/{roomAlias}`: in this case, + currently Synapse restricts its use to the user that created the alias, and + server admins. + + It is proposed to extend this to local users who have a power-level + sufficient to send an `m.room.canonical_alias` event in the room that the + alias currently points to. + + * [`PUT /_matrix/client/r0/directory/list/room/{roomId}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-list-room-roomid) + and the corresponding unspecced `DELETE` api (both of which set the + visibility of a room in the public directory): currently Synapse restricts + their use to server admins and local users who have a PL sufficient to send + an `m.room.aliases` event in the room (ignoring the special auth + rules). This will be changed to check against the PL required to send an + `m.room.canonical_alias` event. + +It is envisaged that Matrix clients will then change their "Room Settings" user +interface to display the aliases from `m.room.canonical_alias` instead of those +in `m.room.aliases`, as well as giving moderators the ability to update that +list. Clients might also wish to use the new `GET +/_matrix/client/r0/rooms/{roomId}/aliases` endpoint to obtain and display the +currently-available local aliases, though given that this list may be subject +to abuse, it should probably not be shown by default. + +### Future work + +This work isn't considered part of this MSC, but rather a potential extension +for the future. + + * It may be useful to be able to query remote servers for their alias + list. This could be done by extending `GET + /_matrix/client/r0/rooms/{roomId}/aliases` to take a `server_name` + parameter, and defining an API in the server_server spec which will expose + the requested information, subject to the calling homeserver having at least + one user with a right to see it. + + * Similarly, room moderators may wish to be able to delete aliases on a remote + server for their room. We could envisage a fedaration API which allows such + a request to be made, subject to the calling homeserver having at least one + moderator in the room. + +## Potential issues + +The biggest problem with this proposal is that existing clients, which rely on +`m.room.aliases` in one way or another, will lose functionality. In particular, +they may not know about aliases that exist, or they may look at outdated +`m.room.aliases` events that list aliases that no longer exist. However, since +`m.room.aliases` is best-effort anyway, these are both problems that exist to +some extent today. + +## Alternatives + +We considered continuing to use `m.room.aliases` to advertise room aliases +instead of `m.room.canonical_alias`, but the significant changes in semantics +made that seem inappropriate. + +We also considered using separate state events for each advertised alias, +rather than listing them all in one event. This might increase the number of +aliases which can be advertised, and help to reduce races when editing the +list. However, the 64KB limit of an event still allows room for hundreds of +aliases of any sane length, and we don't expect the list to be changing +frequently enough for races to be a practical concern. Ultimately the added +complexity seemed redundant. + +A previous suggestion was +[MSC2260](https://github.com/matrix-org/matrix-doc/issues/2260), which proposed +keeping `m.room.aliases` largely as-is, but giving room moderators tools to +control who can send them via room power-levels. We dismissed it for the +reasons set out at +https://github.com/matrix-org/matrix-doc/pull/2260#issuecomment-584207073. + +## Security considerations + +None currently identified. + +## Unstable prefix + +TBD. From 95ff26679bf4f780509e73d2201cafe9ce40c111 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 11 Feb 2020 11:16:56 +0000 Subject: [PATCH 03/79] Apply suggestions from code review Co-Authored-By: Matthew Hodgson Co-Authored-By: Hubert Chathi --- proposals/2432-revised-alias-publishing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 8ef08f7d..0afdf195 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -32,7 +32,7 @@ We propose that that room moderators should be able to manually curate a list of "official" aliases for their room, instead of matrix servers automatically publishing lists of all room aliases into the room state. No particular guarantees are offered that this alias list is entirely accurate: it becomes -room moderators' responsibilty to keep it so. +room moderators' responsibility to keep it so. Meanwhile, the aliases that map to a given room on a given server become the ultimate responsibility of the administrators of that server. We give them @@ -182,7 +182,7 @@ for the future. one user with a right to see it. * Similarly, room moderators may wish to be able to delete aliases on a remote - server for their room. We could envisage a fedaration API which allows such + server for their room. We could envisage a federation API which allows such a request to be made, subject to the calling homeserver having at least one moderator in the room. From c7942d1cecda30511a10d5b971cb58bb30fa9be3 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 12 Feb 2020 21:58:57 -0700 Subject: [PATCH 04/79] Spec moderation policy rooms (MSC2313) MSC: https://github.com/matrix-org/matrix-doc/pull/2313 --- event-schemas/examples/m.policy.rule.room | 10 ++ event-schemas/examples/m.policy.rule.server | 10 ++ event-schemas/examples/m.policy.rule.user | 10 ++ event-schemas/moderation_policy_rule.yaml | 30 ++++ event-schemas/schema/m.policy.rule.room | 15 ++ event-schemas/schema/m.policy.rule.server | 15 ++ event-schemas/schema/m.policy.rule.user | 15 ++ specification/feature_profiles.rst | 2 + specification/modules/moderation_policies.rst | 129 ++++++++++++++++++ specification/targets.yaml | 1 + 10 files changed, 237 insertions(+) create mode 100644 event-schemas/examples/m.policy.rule.room create mode 100644 event-schemas/examples/m.policy.rule.server create mode 100644 event-schemas/examples/m.policy.rule.user create mode 100644 event-schemas/moderation_policy_rule.yaml create mode 100644 event-schemas/schema/m.policy.rule.room create mode 100644 event-schemas/schema/m.policy.rule.server create mode 100644 event-schemas/schema/m.policy.rule.user create mode 100644 specification/modules/moderation_policies.rst diff --git a/event-schemas/examples/m.policy.rule.room b/event-schemas/examples/m.policy.rule.room new file mode 100644 index 00000000..5a532cb5 --- /dev/null +++ b/event-schemas/examples/m.policy.rule.room @@ -0,0 +1,10 @@ +{ + "$ref": "core/state_event.json", + "type": "m.policy.rule.room", + "state_key": "rule:#*:example.org", + "content": { + "entity": "#*:example.org", + "recommendation": "m.ban", + "reason": "undesirable content" + } +} diff --git a/event-schemas/examples/m.policy.rule.server b/event-schemas/examples/m.policy.rule.server new file mode 100644 index 00000000..3d740a28 --- /dev/null +++ b/event-schemas/examples/m.policy.rule.server @@ -0,0 +1,10 @@ +{ + "$ref": "core/state_event.json", + "type": "m.policy.rule.server", + "state_key": "rule:*.example.org", + "content": { + "entity": "*.example.org", + "recommendation": "m.ban", + "reason": "undesirable engagement" + } +} diff --git a/event-schemas/examples/m.policy.rule.user b/event-schemas/examples/m.policy.rule.user new file mode 100644 index 00000000..eb3832da --- /dev/null +++ b/event-schemas/examples/m.policy.rule.user @@ -0,0 +1,10 @@ +{ + "$ref": "core/state_event.json", + "type": "m.policy.rule.user", + "state_key": "rule:@alice*:example.org", + "content": { + "entity": "@alice*:example.org", + "recommendation": "m.ban", + "reason": "undesirable behaviour" + } +} diff --git a/event-schemas/moderation_policy_rule.yaml b/event-schemas/moderation_policy_rule.yaml new file mode 100644 index 00000000..34ad4d9a --- /dev/null +++ b/event-schemas/moderation_policy_rule.yaml @@ -0,0 +1,30 @@ +# Copyright 2020 The Matrix.org Foundation C.I.C. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +properties: + entity: + description: |- + The entity affected by this rule. Glob characters ``*`` and ``?`` can be used + to match zero or more and one or more characters respectively. + type: string + recommendation: + description: The suggested action to take. Currently only ``m.ban`` is specified. + type: string + reason: + description: The human-readable description for the ``recommendation``. + type: string +type: object +required: + - entity + - recommendation + - reason diff --git a/event-schemas/schema/m.policy.rule.room b/event-schemas/schema/m.policy.rule.room new file mode 100644 index 00000000..ff81543e --- /dev/null +++ b/event-schemas/schema/m.policy.rule.room @@ -0,0 +1,15 @@ +--- +allOf: + - $ref: core-event-schema/state_event.yaml +description: A moderation policy rule which affects room IDs and room aliases. +properties: + content: + $ref: "../moderation_policy_rule.yaml" + state_key: + description: An arbitrary string decided upon by the sender. + type: string + type: + enum: + - m.policy.rule.room + type: string +type: object diff --git a/event-schemas/schema/m.policy.rule.server b/event-schemas/schema/m.policy.rule.server new file mode 100644 index 00000000..ca37e8ff --- /dev/null +++ b/event-schemas/schema/m.policy.rule.server @@ -0,0 +1,15 @@ +--- +allOf: + - $ref: core-event-schema/state_event.yaml +description: A moderation policy rule which affects servers. +properties: + content: + $ref: "../moderation_policy_rule.yaml" + state_key: + description: An arbitrary string decided upon by the sender. + type: string + type: + enum: + - m.policy.rule.server + type: string +type: object diff --git a/event-schemas/schema/m.policy.rule.user b/event-schemas/schema/m.policy.rule.user new file mode 100644 index 00000000..4fa65ad8 --- /dev/null +++ b/event-schemas/schema/m.policy.rule.user @@ -0,0 +1,15 @@ +--- +allOf: + - $ref: core-event-schema/state_event.yaml +description: A moderation policy rule which affects users. +properties: + content: + $ref: "../moderation_policy_rule.yaml" + state_key: + description: An arbitrary string decided upon by the sender. + type: string + type: + enum: + - m.policy.rule.user + type: string +type: object diff --git a/specification/feature_profiles.rst b/specification/feature_profiles.rst index bb638380..8a3caf87 100644 --- a/specification/feature_profiles.rst +++ b/specification/feature_profiles.rst @@ -61,6 +61,7 @@ Summary `Stickers`_ Optional Optional Optional Optional Optional `Server ACLs`_ Optional Optional Optional Optional Optional `Server Notices`_ Optional Optional Optional Optional Optional + `Moderation policies`_ Optional Optional Optional Optional Optional ===================================== ========== ========== ========== ========== ========== *Please see each module for more details on what clients need to implement.* @@ -94,6 +95,7 @@ Summary .. _Stickers: `module:stickers`_ .. _Server ACLs: `module:server-acls`_ .. Server Notices already has a link elsewhere. +.. _Moderation Policies: `module:moderation-policies`_ Clients ------- diff --git a/specification/modules/moderation_policies.rst b/specification/modules/moderation_policies.rst new file mode 100644 index 00000000..8992ceb1 --- /dev/null +++ b/specification/modules/moderation_policies.rst @@ -0,0 +1,129 @@ +.. Copyright 2020 The Matrix.org Foundation C.I.C. +.. +.. Licensed under the Apache License, Version 2.0 (the "License"); +.. you may not use this file except in compliance with the License. +.. You may obtain a copy of the License at +.. +.. http://www.apache.org/licenses/LICENSE-2.0 +.. +.. Unless required by applicable law or agreed to in writing, software +.. distributed under the License is distributed on an "AS IS" BASIS, +.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +.. See the License for the specific language governing permissions and +.. limitations under the License. + +Moderation policy lists +======================= + +.. _module:moderation-policies: + +With Matrix being an open network where anyone can participate, a very wide +range of content exists and it is important that users are empowered to select +which content they wish to see, and which content they wish to block. By +extension, room moderators and server admins should also be able to select +which content they do not wish to host in their rooms and servers. + +The protocol's position on this is one of neutrality: it should not be deciding +what content is undesirable for any particular entity and should instead be +empowering those entities to make their own decisions. As such, a generic +framework for communicating "moderation policy lists" or "moderation policy rooms" +is described. Note that this module only describes the data structures and not +how they should be interpreting: the entity making the decisions on filtering +is best positioned to interpret the rules how it sees fit. + +Moderation policy lists are stored as room state events. There are no restrictions +on how the rooms can be configured (they could be public, private, encrypted, etc). + +There are currently 3 kinds of entities which can be affected by rules: ``user``, +``server``, and ``room``. All 3 are described with ``m.policy.rule.`` state +events. The ``state_key`` for a policy rule is an arbitrary string decided by the +sender of the rule. + +Rules contain recommendations and reasons for the rule existing. The ``reason`` +is a human-readable string which describes the ``recommendation``. Currently only +one recommendation, ``m.ban``, is specified. + +``m.ban`` recommendation +------------------------ + +When this recommendation is used, the entities affected by the rule should be +banned from participation where possible. The enforcement of this is deliberately +left as an implementation detail to avoid the protocol imposing its opinion on how +the policy list is to be interpreted. However, a suggestion for a simple implementation +is as follows: + +* Is a ``user`` rule... + + * Applied to a user: The user should be added to the subscriber's ignore list. + * Applied to a room: The user should be banned from the room (either on sight or immediately). + * Applied to a server: The user should not be allowed to send invites to users on the server. + +* Is a ``room`` rule... + + * Applied to a user: The user should leave the room and not join it + (`MSC2270 `_-style ignore). + * Applied to a room: No-op because a room cannot ban itself. + * Applied to a server: The server should prevent users from joining the room and from receiving + invites to it. + +* Is a ``server`` rule... + + * Applied to a user: The user should not receive events or invites from the server. + * Applied to a room: The server is added as a denied server in the ACLs. + * Applied to a server: The subscriber should avoid federating with the server as much as + possible by blocking invites from the server and not sending traffic unless strictly + required (no outbound invites). + +Subscribing to policy lists +--------------------------- + +This is deliberatly left as an implementation detail. For implementations using the +Client-Server API, this could be as easy as joining or peeking the room. Joining or peeking +is not required, however: an implementation could poll for updates or use a different +technique for receiving updates to the policy's rules. + +Sharing +------- + +In addition to sharing a direct reference to the room which contains the policy's rules, +plain http or https URLs can be used to share links to the list. When the URL is approached +with a ``Accept: application/json`` header or has ``.json`` appended to the end of the URL, it +should return a JSON object containing a ``room_uri`` property which references the room. +Currently this would be a ``matrix.to`` URI, however in future it could be a Matrix-schemed +URI instead. When not approached with the intent of JSON, the service could return a +user-friendly page describing what is included in the ban list. + +Events +------ + +The ``entity`` described by the state events can contain ``*`` and ``?`` to match zero or more +and one or more characters respectively. Note that rules against rooms can describe a room ID +or room alias - the subscriber is responsible for resolving the alias to a room ID if desired. + +{{m_policy_rule_user_event}} + +{{m_policy_rule_room_event}} + +{{m_policy_rule_server_event}} + +Client behaviour +---------------- +As described above, the client behaviour is deliberatly left undefined. + +Server behaviour +---------------- +Servers have no additional requirements placed on them by this module. + + +Security considerations +----------------------- +This module could be used to build a system of shared blacklists, which may create +a divide within established communities if not carefully deployed. This may well not +be a suitable solution for all communities. + +Depending on how implementations handle subscriptions, user IDs may be linked to +policy lists and therefore expose the views of that user. For example, a client implementation +which joins the user to the policy room would expose the user's ID to observers of the +policy room. In future, `MSC1228 `_ +and `MSC1777 `_ (or similar) could +help solve this concern. diff --git a/specification/targets.yaml b/specification/targets.yaml index 2cd911ba..4e0b068d 100644 --- a/specification/targets.yaml +++ b/specification/targets.yaml @@ -91,6 +91,7 @@ groups: # reusable blobs of files when prefixed with 'group:' - modules/mentions.rst - modules/room_upgrades.rst - modules/server_notices.rst + - modules/moderation_policies.rst title_styles: ["=", "-", "~", "+", "^", "`", "@", ":"] From da047523e32a863c7c0d0704a7c89787920b9310 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 12 Feb 2020 22:00:56 -0700 Subject: [PATCH 05/79] Changelog --- changelogs/client_server/newsfragments/2434.feature | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2434.feature diff --git a/changelogs/client_server/newsfragments/2434.feature b/changelogs/client_server/newsfragments/2434.feature new file mode 100644 index 00000000..2b8f36f5 --- /dev/null +++ b/changelogs/client_server/newsfragments/2434.feature @@ -0,0 +1 @@ +Added data structures for defining moderation policies in rooms per `MSC2313 `_. From 7a878bb6c34c2f39507de63a8a2416196d90f05b Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 12 Feb 2020 22:01:58 -0700 Subject: [PATCH 06/79] Fix location of changelog entries and synergize them --- changelogs/client_server/{ => newsfragments}/2245.clarification | 0 changelogs/client_server/newsfragments/2415.clarification | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename changelogs/client_server/{ => newsfragments}/2245.clarification (100%) diff --git a/changelogs/client_server/2245.clarification b/changelogs/client_server/newsfragments/2245.clarification similarity index 100% rename from changelogs/client_server/2245.clarification rename to changelogs/client_server/newsfragments/2245.clarification diff --git a/changelogs/client_server/newsfragments/2415.clarification b/changelogs/client_server/newsfragments/2415.clarification index d1a7dbfe..902a9c3f 100644 --- a/changelogs/client_server/newsfragments/2415.clarification +++ b/changelogs/client_server/newsfragments/2415.clarification @@ -1 +1 @@ -Fix misspelling of _deprecated_. \ No newline at end of file +Fix various spelling errors throughout the specification. From 6d475ebd5777600e70ed0737845f9b5d21bba59a Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Mon, 17 Feb 2020 12:56:28 -0700 Subject: [PATCH 07/79] Remove whitespace Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- specification/modules/moderation_policies.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/specification/modules/moderation_policies.rst b/specification/modules/moderation_policies.rst index 8992ceb1..2e85fb07 100644 --- a/specification/modules/moderation_policies.rst +++ b/specification/modules/moderation_policies.rst @@ -114,7 +114,6 @@ Server behaviour ---------------- Servers have no additional requirements placed on them by this module. - Security considerations ----------------------- This module could be used to build a system of shared blacklists, which may create From 786772f7646f8767c008872abc6fc41b9fe7b809 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 18 Feb 2020 16:24:46 +0000 Subject: [PATCH 08/79] Update proposals/2432-revised-alias-publishing.md Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/2432-revised-alias-publishing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 0afdf195..a6887264 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -81,7 +81,7 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and empty. This means that no alias has been picked out as the 'main' alias. (Note: although the spec currently claims that `alias` is mandatory, Synapse - generates `m.room.canonical` alias events with no `alias` property when the + generates `m.room.canonical_alias` events with no `alias` property when the main alias is deleted. This change would legitimise that behaviour.) (For clarity: it is not proposed that the `alt_aliases` be considered when From 645dbcc0912624a32d070b2c7ae30d936f1e2f7b Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:25:34 +0000 Subject: [PATCH 09/79] make room alias lists peekable --- proposals/2432-revised-alias-publishing.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index a6887264..4a5d95ad 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -128,11 +128,8 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and ``` This API can be called by any current member of the room (calls from other - users result in `M_FORBIDDEN`). - - TODO: should this be tied in with `history_visibilty` to allow peeking from - non-members? On the one hand that feels like pointless clutter; on the other - it feels like it makes it more consistent with peekable rooms. + users result in `M_FORBIDDEN`). For rooms with `history_visibility` set to + `world_readable`, it can also be called by users outside the room. Various APIs are currently subject to implementation-defined access restrictions. No change to the specification is changed in this regard From 30d762cc72ad179ceb612dea046418770546714e Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:25:49 +0000 Subject: [PATCH 10/79] document unstable prefixes/feature flags --- proposals/2432-revised-alias-publishing.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 4a5d95ad..81d59e71 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -219,4 +219,11 @@ None currently identified. ## Unstable prefix -TBD. +While this feature is in development, the following names will be in use: + +| Proposed final name | Name while in development | +| `GET /_matrix/client/r0/rooms/{roomId}/aliases` | `GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases` | + +Servers will indicate support for the new endpoint via a non-empty value for feature flag +`org.matrix.msc2432` in `unstable_features` in the response to `GET +/_matrix/client/versions`. From 98a6cd0f45426beca4eb1e0334573a1ea3748642 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 19 Feb 2020 07:29:55 +0000 Subject: [PATCH 11/79] fix table --- proposals/2432-revised-alias-publishing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 81d59e71..c527a14e 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -222,6 +222,7 @@ None currently identified. While this feature is in development, the following names will be in use: | Proposed final name | Name while in development | +| --- | --- | | `GET /_matrix/client/r0/rooms/{roomId}/aliases` | `GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases` | Servers will indicate support for the new endpoint via a non-empty value for feature flag From 8b9ea10e11bd0a460211e1826543fe17f2667e19 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 19 Feb 2020 07:31:57 +0000 Subject: [PATCH 12/79] server admins can list aliases --- proposals/2432-revised-alias-publishing.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index c527a14e..433ce0f6 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -131,6 +131,9 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and users result in `M_FORBIDDEN`). For rooms with `history_visibility` set to `world_readable`, it can also be called by users outside the room. + Servers might also choose to allow access to other users such as server + administrators. + Various APIs are currently subject to implementation-defined access restrictions. No change to the specification is changed in this regard (implementations will continue to be free to impose their own From e151ba96acfbd67febc1869c0326b1fb7c4c4dc7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=96rjan=20Fors?= Date: Mon, 24 Feb 2020 09:45:46 +0100 Subject: [PATCH 13/79] Fix typo for upgrade MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Örjan Fors --- api/client-server/room_upgrades.yaml | 2 +- changelogs/client_server.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/api/client-server/room_upgrades.yaml b/api/client-server/room_upgrades.yaml index 55ee14dc..3aaaadcb 100644 --- a/api/client-server/room_upgrades.yaml +++ b/api/client-server/room_upgrades.yaml @@ -90,4 +90,4 @@ paths: schema: "$ref": "definitions/errors/error.yaml" tags: - - Room ugprades + - Room upgrades diff --git a/changelogs/client_server.rst b/changelogs/client_server.rst index a5173fd0..bc12da5c 100644 --- a/changelogs/client_server.rst +++ b/changelogs/client_server.rst @@ -74,7 +74,7 @@ Backwards Compatible Changes - Support optional features by having clients query for capabilities. (`#1829 `_, `#1879 `_) - Add ``M_RESOURCE_LIMIT_EXCEEDED`` as an error code for when homeservers exceed limits imposed on them. (`#1874 `_) - Emit ``M_UNSUPPORTED_ROOM_VERSION`` error codes where applicable on ``/createRoom`` and ``/invite`` APIs. (`#1908 `_) -- Add a ``.m.rule.tombstone`` default push rule for room ugprade notifications. (`#2020 `_) +- Add a ``.m.rule.tombstone`` default push rule for room upgrade notifications. (`#2020 `_) - Add support for sending server notices to clients. (`#2026 `_) - Add MSISDN (phone number) support to User-Interactive Authentication. (`#2030 `_) - Add the option to lazy-load room members for increased client performance. (`#2035 `_) From 4e123ca12113bd0587ac641503f0e8da9f6af4f0 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Sat, 29 Feb 2020 23:29:33 +0000 Subject: [PATCH 14/79] Update proposals/2432-revised-alias-publishing.md Co-Authored-By: Kitsune Ral --- proposals/2432-revised-alias-publishing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index 433ce0f6..dff72df5 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -135,7 +135,7 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and administrators. Various APIs are currently subject to implementation-defined access -restrictions. No change to the specification is changed in this regard +restrictions. No change to the specification is introduced in this regard (implementations will continue to be free to impose their own restrictions). Nevertheless as part of this MSC it is useful to consider some proposed changes to Synapse's implementation: From 420180a69ddd25d44b1c7c048d809b05683978f4 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 12:30:19 -0500 Subject: [PATCH 15/79] MSC: Remove query_auth federation endpoint. --- .gitignore | 1 + ...x-remove-query_auth-federation-endpoint.md | 31 +++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 proposals/xxxx-remove-query_auth-federation-endpoint.md diff --git a/.gitignore b/.gitignore index 800be2fa..9cc27b85 100644 --- a/.gitignore +++ b/.gitignore @@ -12,3 +12,4 @@ *.swp _rendered.rst /.vscode/ +/.idea/ diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/xxxx-remove-query_auth-federation-endpoint.md new file mode 100644 index 00000000..7930c5f8 --- /dev/null +++ b/proposals/xxxx-remove-query_auth-federation-endpoint.md @@ -0,0 +1,31 @@ +# MSCxxxx: Remove the `query_auth` federation endpoint + +The `query_auth` federation endpoint is unused by Synapse and should be removed. +The current implementation in Synapse is broken and will return a 500 error in +some situations. + +## Proposal + +Remove: + +* [POST `/_matrix/federation/v1/query_auth/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.3#post-matrix-federation-v1-query-auth-roomid-eventid) + +## Potential issues + +Removing this endpoint impacts backwards compatibility. + +In practice, removing this endpoint should have minimal impact. Since 1.5.0rc1 +of Synapse this endpoint is not called (see [#6214](https://github.com/matrix-org/synapse/pull/6214)). +During removal it was noted that the code to call this endpoint was already +unreachable. + +Note that it seems like this was initially supported in Synapse v0.7.0. It is +not clear at what point it became unused. + +## Alternatives + +The endpoint could be deprecated in removed in a future version of the specification. + +## Security considerations + +None. From c3420770ad3a559217ee5ae7a5998b1c78960055 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 13:15:32 -0500 Subject: [PATCH 16/79] Clarify history of endpoint. --- ...x-remove-query_auth-federation-endpoint.md | 33 +++++++++++++------ 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/xxxx-remove-query_auth-federation-endpoint.md index 7930c5f8..387f2efa 100644 --- a/proposals/xxxx-remove-query_auth-federation-endpoint.md +++ b/proposals/xxxx-remove-query_auth-federation-endpoint.md @@ -1,26 +1,39 @@ # MSCxxxx: Remove the `query_auth` federation endpoint The `query_auth` federation endpoint is unused by Synapse and should be removed. -The current implementation in Synapse is broken and will return a 500 error in -some situations. +The current implementation in Synapse is not robust and will return a 500 error +in some situations. ## Proposal -Remove: +Remove the following endpoint: * [POST `/_matrix/federation/v1/query_auth/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.3#post-matrix-federation-v1-query-auth-roomid-eventid) ## Potential issues -Removing this endpoint impacts backwards compatibility. +Removing this endpoint impacts backwards compatibility, in practice removing +this endpoint should have minimal impact as it was an unused error path in +Synapse. The federation client code to call this endpoint was removed in Synapse +v1.5.0rc1. + +Note that dendrite has never implemented this federation endpoint. + +### History + +This endpoint (and the federation client code) to call it was initially +added in Synapse v0.7.0 (see [#43](https://github.com/matrix-org/synapse/pull/43)). +The federation client code was heavily modified for v1.0.0rc1 (see +[#5227](https://github.com/matrix-org/synapse/pull/5227/)), + +The federation client code to call this endpoint was removed in v1.5.0rc1 of +Synapse (see [#6214](https://github.com/matrix-org/synapse/pull/6214). After +that point this endpoint is not called). -In practice, removing this endpoint should have minimal impact. Since 1.5.0rc1 -of Synapse this endpoint is not called (see [#6214](https://github.com/matrix-org/synapse/pull/6214)). During removal it was noted that the code to call this endpoint was already -unreachable. - -Note that it seems like this was initially supported in Synapse v0.7.0. It is -not clear at what point it became unused. +unreachable. It seems that this code was never reachable and was meant for an +error situation which was never built out (see `git log -S NOT_ANCESTOR`, the +error condition is never assigned). ## Alternatives From 6754d5ba5f4e98ed67c5771a7176cd7d3ecba582 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 3 Mar 2020 16:18:59 -0500 Subject: [PATCH 17/79] Move filename based on MSC #. --- ...ndpoint.md => 2451-remove-query_auth-federation-endpoint.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-remove-query_auth-federation-endpoint.md => 2451-remove-query_auth-federation-endpoint.md} (96%) diff --git a/proposals/xxxx-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md similarity index 96% rename from proposals/xxxx-remove-query_auth-federation-endpoint.md rename to proposals/2451-remove-query_auth-federation-endpoint.md index 387f2efa..d5c2af4d 100644 --- a/proposals/xxxx-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -1,4 +1,4 @@ -# MSCxxxx: Remove the `query_auth` federation endpoint +# MSC2451: Remove the `query_auth` federation endpoint The `query_auth` federation endpoint is unused by Synapse and should be removed. The current implementation in Synapse is not robust and will return a 500 error From 68357a7d23420b069308cfbe99244168307230d6 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 4 Mar 2020 07:31:38 -0500 Subject: [PATCH 18/79] Fix a typo in -> and. Co-Authored-By: Matthew Hodgson --- proposals/2451-remove-query_auth-federation-endpoint.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2451-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md index d5c2af4d..0d84069e 100644 --- a/proposals/2451-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -37,7 +37,7 @@ error condition is never assigned). ## Alternatives -The endpoint could be deprecated in removed in a future version of the specification. +The endpoint could be deprecated and removed in a future version of the specification. ## Security considerations From 61715f6452bfda06b273d1fc8a94b9412f4910b6 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 4 Mar 2020 08:07:05 -0500 Subject: [PATCH 19/79] Update and expand the proposal based on feedback and additional info. --- ...1-remove-query_auth-federation-endpoint.md | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/proposals/2451-remove-query_auth-federation-endpoint.md b/proposals/2451-remove-query_auth-federation-endpoint.md index 0d84069e..b2d8bc9f 100644 --- a/proposals/2451-remove-query_auth-federation-endpoint.md +++ b/proposals/2451-remove-query_auth-federation-endpoint.md @@ -1,8 +1,19 @@ # MSC2451: Remove the `query_auth` federation endpoint -The `query_auth` federation endpoint is unused by Synapse and should be removed. -The current implementation in Synapse is not robust and will return a 500 error -in some situations. +This API was added without sufficient thought nor testing. The endpoint isn't +used in any known implementations, and we do not believe it to be necessary +for federation to work. The only known implementation (in Synapse) was not fully +fleshed out and is broken. + +For background, the idea behind this endpoint was that two homeservers would be +able to share state events with the hope of filling in missing state from one +of homeservers allowing state resolution to complete. This was to protect +against a joining server not providing the full (or providing stale) state. + +In addition to the ideas above not coming to fruition, it is unclear whether the +current design of this endpoint would be sufficient. If this state negotiation +feature is needed in the future it should be redesigned from scratch via the MSC +proposal process. ## Proposal @@ -17,7 +28,8 @@ this endpoint should have minimal impact as it was an unused error path in Synapse. The federation client code to call this endpoint was removed in Synapse v1.5.0rc1. -Note that dendrite has never implemented this federation endpoint. +There is no evidence of other homeserver implementations having implemented this +endpoint. ### History From 438ff8fc1d19f89cbf77583b95a3dbe55d4c6b96 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Thu, 5 Mar 2020 21:02:09 +0000 Subject: [PATCH 20/79] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Travis Ralston --- proposals/2422-allow-color-attribute-on-font-tag.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 4287a696..7a87f143 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -1,6 +1,6 @@ # MSC2422: Allow `color` as attribute for `` in messages -Currently the spec requires you to use `data-mx-color` instead of the standard +Currently the spec recommends that you to use `data-mx-color` instead of the standard `color` html attribute for the `` tag. This is probably done to make it consistent with ``, where you may not want to allow a generic style tag for. @@ -35,4 +35,3 @@ Add the `color` attribute to the allowed attributes of `` in section - Add a section to tell the clients to prefer `color` over `mx-data-color` - Spec an entirely different format for messages (that would probably not make this proposal obsolete) - From 6b2752c4c2c0fd183224f22ed339226362ddddfd Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Thu, 5 Mar 2020 21:02:23 +0000 Subject: [PATCH 21/79] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Travis Ralston --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 7a87f143..9e4b1645 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -15,7 +15,7 @@ It would probably be for the best to allow or even prefer `color` on the ## Proposal Add the `color` attribute to the allowed attributes of `` in section -13.2.1.7. Allow only hexcodes as allowed value for this attribute for now. +13.2.1.7. No changes to the allowable values from the HTML spec are made here. ## Potential issues From e6c7eac023e6b55404fa14d9eebf9e462f097f67 Mon Sep 17 00:00:00 2001 From: Runster Date: Fri, 6 Mar 2020 18:11:28 +0100 Subject: [PATCH 22/79] Correct name of Phil Zimmermann --- specification/modules/end_to_end_encryption.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/modules/end_to_end_encryption.rst b/specification/modules/end_to_end_encryption.rst index af7b2c59..631b182a 100644 --- a/specification/modules/end_to_end_encryption.rst +++ b/specification/modules/end_to_end_encryption.rst @@ -505,7 +505,7 @@ framework outlined above. SAS verification is intended to be a highly interactiv process for users, and as such exposes verfiication methods which are easier for users to use. -The verification process is heavily inspired by Phil Zimmerman's ZRTP key agreement +The verification process is heavily inspired by Phil Zimmermann's ZRTP key agreement handshake. A key part of key agreement in ZRTP is the hash commitment: the party that begins the Diffie-Hellman key sharing sends a hash of their part of the Diffie-Hellman exchange, and does not send their part of the Diffie-Hellman exchange until they have From 7666b9fea71ff2129cc4690ae45e9d2a2e6fc58e Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 6 Mar 2020 10:56:19 -0700 Subject: [PATCH 23/79] Add changelog for name correction https://github.com/matrix-org/matrix-doc/pull/2453 --- changelogs/client_server/newsfragments/2453.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2453.clarification diff --git a/changelogs/client_server/newsfragments/2453.clarification b/changelogs/client_server/newsfragments/2453.clarification new file mode 100644 index 00000000..902a9c3f --- /dev/null +++ b/changelogs/client_server/newsfragments/2453.clarification @@ -0,0 +1 @@ +Fix various spelling errors throughout the specification. From b760ec2d747281294634bec051064191d4fd3357 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Sat, 7 Mar 2020 14:57:32 +0100 Subject: [PATCH 24/79] Add comments why alternatives to MSC2422 weren't chosen --- .../2422-allow-color-attribute-on-font-tag.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 9e4b1645..3fb03aa5 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -29,9 +29,11 @@ Add the `color` attribute to the allowed attributes of `` in section ## Alternatives -- fix the clients -- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving - us just with `color` for `` -- Add a section to tell the clients to prefer `color` over `mx-data-color` -- Spec an entirely different format for messages (that would probably not make - this proposal obsolete) +- fix the clients + -> This currently seems not feasible. Multiple clients started using color first (i.e. RiotX, Gomuks) and if it isn't spelled out explicitly in the spec, this will probably continue. +- remove the `data-mx-color` and `data-mx-bg-color` attributes entirely, leaving us just with `color` for `` + -> This would break old messages and can be done independently of this proposal at a later date, if it is deemed useful. +- Add a section to tell the clients to prefer `color` over `mx-data-color` + -> I don't really know, why mx-data-* was chosen, but I assume there was a reason, so I don't want to change that. +- Spec an entirely different format for messages (that would probably not make this proposal obsolete) + -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is dicouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. From 2d85422a2ff500cb79fcf88c82fa5c73fc4f4b1a Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Sat, 7 Mar 2020 18:34:07 +0000 Subject: [PATCH 25/79] Update proposals/2422-allow-color-attribute-on-font-tag.md Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 3fb03aa5..11f06bff 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -19,7 +19,7 @@ Add the `color` attribute to the allowed attributes of `` in section ## Potential issues -- We now have a redundant attribute in the spec. While it matches, what the +- We now have a redundant attribute in the spec. While it matches what the clients currently do, it may be better to fix each client instead. - Clients may not sanitize the color attribute and will let other color values through, increasing compatibility issues again. From c69a747bae52296f8a7fe930090c64c98227cd73 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 12:31:06 -0400 Subject: [PATCH 26/79] Convert the initial Google Doc to Markdown. --- proposals/xxxx-ui-interactive-auth-for-sso.md | 262 ++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 proposals/xxxx-ui-interactive-auth-for-sso.md diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/xxxx-ui-interactive-auth-for-sso.md new file mode 100644 index 00000000..fc7413fe --- /dev/null +++ b/proposals/xxxx-ui-interactive-auth-for-sso.md @@ -0,0 +1,262 @@ +# User-Interactive Auth for SSO-backed homeservers + +## Background + +Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and +`POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their +identity, as a guard against a leaked access token being used to take over an +entire account. + +On a normal homeserver, this is done by prompting the user to enter their +password. However, on a homeserver where users authenticate via a single-sign-on +system, the user doesn't have a password, so this doesn't work. Instead we need +to delegate that check to the SSO system. + +At the protocol level, this means adding support for SSO to +[user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). + +### The current implementation + +Or, "how UI Auth works, in practice": + +When the client calls one of the protected endpoints, it initially returns a 401 +response. For example: + +``` +POST /_matrix/client/r0/delete_devices HTTP/1.1 +Content-Type: application/json + +{ + "devices": ["FSVVTZRRAA"] +} + +HTTP/1.1 401 Unauthorized +Content-Type: application/json + +{ + "flows": [ + { + "stages": [ + "m.login.password" + ] + } + ], + "params": {}, + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" +} +``` + +The client: + +* inspects the "flows" list +* discovers there is a flow it knows how to follow +* carries out the first "stage" of that flow (m.login.password) + +ie, the client prompts the user to enter a password. + +The client then resubmits with an additional 'auth' param, with "type" giving +the name of the authentication type it has just carried out. That completes the +authentication flow, so the server is now happy, and returns a 200: + +``` +POST /_matrix/client/r0/delete_devices HTTP/1.1 +Content-Type: application/json + +{ + "devices": ["FSVVTZRRAA"], + "auth": { + "session":"dTKfsLHSAJeAhqfxUsvrIVJd", + "type":"m.login.password", + "identifier":{"type":"m.id.user", "user":"@userid:matrix.org"}, + "password":"" + } +} + + +HTTP/1.1 200 OK +Content-Type: application/json +Content-Length: 179 + +{} +``` + +## Proposal + +We add an `m.login.sso` authentication type to the UI auth spec. There are no +additional params as part of this auth type. + +1. If the client wants to complete that authentication type, it opens a browser + window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` + with session set to the UI-Auth session id (from the "auth" dict). + + The homeserver returns a page which says words to the effect of "A client is + trying to remove a device/add an email address/take over your account. To + confirm this action, **re-authenticate with single sign-on**. If you did not + expect this, your account may be compromised!" + + See security section below. +2. The link, once the user clicks on it, goes to the SSO provider's page. +3. The SSO provider validates the user, and redirects the browser back to the + homeserver. +4. The homeserver validates the response from the SSO provider, updates the + user-interactive auth session to show that the SSO has completed, serves the + fallback auth completion page as specced: + https://matrix.org/docs/spec/client_server/r0.6.0#fallback +5. The client resubmits its original request, with its original session id, + which now hopefully completes. + +Note that the post-SSO URL on the homeserver is left up to the homeserver +implementation rather than forming part of the spec. + +* SAML2 servers typically only support one URL per service provider, so in + practice it will need to be the same as that already used for the login flow + (for synapse, it's /_matrix/saml2/authn_response) - and the server needs to + be able to figure out if it's doing SSO for a login attempt or an SSO + attempt. +* CAS doesn't have the same restriction. + +### Example flow: + +0. Client submits the request, which the server says requires SSO: + + ``` + POST /_matrix/client/r0/delete_devices HTTP/1.1 + Content-Type: application/json + Authorization: Bearer xyzzy + + { + "devices": ["FSVVTZRRAA"] + } + + HTTP/1.1 401 Unauthorized + Content-Type: application/json + + { + "flows": [ + { + "stages": [ + "m.login.sso" + ] + } + ], + "params": {}, + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" + } + ``` + +1. Client opens a browser window for the fallback endpoint: + + ``` + GET /_matrix/client/r0/auth/m.login.sso/fallback/web + ?session=dTKfsLHSAJeAhqfxUsvrIVJd HTTP/1.1 + + HTTP/1.1 200 OK + + + can delete device pls? + clicky + + ``` + +2. The user clicks the confirmation link which goes to the SSO provider's site: + + ``` + GET https://sso_provider/validate?SAMLRequest= HTTP/1.1 + + ... SAML/CAS stuff + ``` + +3. The SSO provider validates the user and ends up redirecting the browser back + to the homeserver. (The example below shows a 302 for simplicity but SAML normally uses a 200 with an html
, with javascript to automatically submit it.) + + ``` + HTTP/1.1 302 Moved + Location: https://homeserver/_matrix/saml2/authn_response? + SAMLResponse= + ``` + +4. The browser sends the SSO response to the homeserver, which validates it and + shows the fallback auth completion page: + + ``` + GET /_matrix/saml2/authn_response?SAMLResponse= + + + HTTP/1.1 200 OK + + + +

Thank you.

+

You may now close this window and return to the application.

+ ``` + +5. The client closes the browser popup if it is still open, and resubmits its + original request, which now succeeds: + + ``` + POST /_matrix/client/r0/delete_devices HTTP/1.1 + Content-Type: application/json + Authorization: Bearer xyzzy + + { + "auth": { + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" + } + } + + HTTP/1.1 200 OK + Content-Type: application/json + + {} + ``` + +A few notes: + +* The security of this relies on UI-Auth sessions only being used for the same + request as they were initiated for. I don't think that's currently enforced. +* We might consider an alternative client flow where the fallback auth ends up + redirecting to a given URI, instead of doing javascript postMessage foo. I + think that's an orthogonal change to the fallback auth though. +* In theory, any clients that already implement the fallback process for + unknown authentication types will work fine without modification. + Unfortunately, I don't think Riot (on any platform) is among them. + +## Security considerations + +Recall that the thing we are trying to guard against here is a single leaked +access-token being used to take over an entire account. So let's assume the +attacker has got hold of an access token for your account. What happens if we + skip the confirmation step? + +The attacker, who has your access token, starts a UI-Auth session to add his +email address to your account. + +He then sends you a link "hey, check out this cool video!"; the link leads (via +an innocent-looking url shortener) to +`/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`, with the ID of +the session that he just created. + +Recall that we're skipping the confirmation step, so the server redirects +straight to the SSO provider. + +It's common for SSO providers to redirect straight back to the app if you've +recently authenticated with them; even in the best case, the SSO provider shows +some innocent message along the lines of "Confirm that you want to sign in to +". + +So the SSO completes, and the attacker's session is validated. + +By telling the user what's about to happen as clearly as we can, and making them +confirm, we can mitigate this problem. + +## Unstable prefix + +We should use a vendor prefix here until this hits the spec. + +`org.matrix.login.sso` ? \ No newline at end of file From f48bbd32788ec8734fbaaa85728197632aeffd61 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 14:00:28 -0400 Subject: [PATCH 27/79] Attempt to clarify the MSC. --- proposals/xxxx-ui-interactive-auth-for-sso.md | 90 ++++++++++--------- 1 file changed, 47 insertions(+), 43 deletions(-) diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/xxxx-ui-interactive-auth-for-sso.md index fc7413fe..5b6f396d 100644 --- a/proposals/xxxx-ui-interactive-auth-for-sso.md +++ b/proposals/xxxx-ui-interactive-auth-for-sso.md @@ -1,6 +1,4 @@ -# User-Interactive Auth for SSO-backed homeservers - -## Background +# User-Interactive Auth for SSO-backed homeserver Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and `POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their @@ -9,15 +7,17 @@ entire account. On a normal homeserver, this is done by prompting the user to enter their password. However, on a homeserver where users authenticate via a single-sign-on -system, the user doesn't have a password, so this doesn't work. Instead we need -to delegate that check to the SSO system. +system, the user doesn't have a password registered with the homeserver. Instead +we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to [user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -### The current implementation +In theory, any clients that already implement the fallback process for unknown +authentication types will work fine without modification. It is unknown whether +this is widely supported among clients. -Or, "how UI Auth works, in practice": +### UI Auth Overview When the client calls one of the protected endpoints, it initially returns a 401 response. For example: @@ -52,7 +52,7 @@ The client: * discovers there is a flow it knows how to follow * carries out the first "stage" of that flow (m.login.password) -ie, the client prompts the user to enter a password. +In this example, the client prompts the user to enter a password. The client then resubmits with an additional 'auth' param, with "type" giving the name of the authentication type it has just carried out. That completes the @@ -89,24 +89,25 @@ additional params as part of this auth type. window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` with session set to the UI-Auth session id (from the "auth" dict). - The homeserver returns a page which says words to the effect of "A client is - trying to remove a device/add an email address/take over your account. To - confirm this action, **re-authenticate with single sign-on**. If you did not - expect this, your account may be compromised!" + The homeserver returns a page which asks for the user's confirmation before + proceeding. See the security considerations section below for why this is + necessary. For example, the page could say words to the effect of: - See security section below. + > A client is trying to remove a device/add an email address/take over your + > account. To confirm this action, **re-authenticate with single sign-on**. + > If you did not expect this, your account may be compromised! 2. The link, once the user clicks on it, goes to the SSO provider's page. 3. The SSO provider validates the user, and redirects the browser back to the homeserver. 4. The homeserver validates the response from the SSO provider, updates the - user-interactive auth session to show that the SSO has completed, serves the - fallback auth completion page as specced: - https://matrix.org/docs/spec/client_server/r0.6.0#fallback + user-interactive auth session to show that the SSO has completed, + [serves the fallback auth completion page as specced](https://matrix.org/docs/spec/client_server/r0.6.0#fallback). 5. The client resubmits its original request, with its original session id, - which now hopefully completes. + which now should complete. Note that the post-SSO URL on the homeserver is left up to the homeserver -implementation rather than forming part of the spec. +implementation rather than forming part of the specification, choices might be +limited by the chosen SSO implementation, for example: * SAML2 servers typically only support one URL per service provider, so in practice it will need to be the same as that already used for the login flow @@ -216,47 +217,50 @@ implementation rather than forming part of the spec. {} ``` -A few notes: +## Alternatives -* The security of this relies on UI-Auth sessions only being used for the same - request as they were initiated for. I don't think that's currently enforced. -* We might consider an alternative client flow where the fallback auth ends up - redirecting to a given URI, instead of doing javascript postMessage foo. I - think that's an orthogonal change to the fallback auth though. -* In theory, any clients that already implement the fallback process for - unknown authentication types will work fine without modification. - Unfortunately, I don't think Riot (on any platform) is among them. +An alternative client flow where the fallback auth ends up redirecting to a +given URI, instead of doing JavaScript postMessage foo could be considered. +This is probably an orthogonal change to the fallback auth though. ## Security considerations +### Why we need user to confirm before the SSO flow + Recall that the thing we are trying to guard against here is a single leaked access-token being used to take over an entire account. So let's assume the -attacker has got hold of an access token for your account. What happens if we - skip the confirmation step? +attacker has got hold of an access token for your account. What happens if the +confirmation step is skipped? -The attacker, who has your access token, starts a UI-Auth session to add his -email address to your account. +The attacker, who has your access token, starts a UI Authentication session to +add their email address to your account. -He then sends you a link "hey, check out this cool video!"; the link leads (via -an innocent-looking url shortener) to +They then sends you a link "hey, check out this cool video!"; the link leads (via +an innocent-looking URL shortener or some other phishing technique) to `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`, with the ID of the session that he just created. -Recall that we're skipping the confirmation step, so the server redirects -straight to the SSO provider. +Since there is no confirmation step, the server redirects directly to the SSO +provider. It's common for SSO providers to redirect straight back to the app if you've recently authenticated with them; even in the best case, the SSO provider shows -some innocent message along the lines of "Confirm that you want to sign in to -". +an innocent message along the lines of "Confirm that you want to sign in to +". -So the SSO completes, and the attacker's session is validated. +After redirecting back to the homeserver, the SSO is completed and the +attacker's session is validated. They are now able to make their malicious +change to your account. -By telling the user what's about to happen as clearly as we can, and making them -confirm, we can mitigate this problem. +This problem can be mitigated by clearly telling the user what is about to happen. + +### Reusing UI-Auth sessions + +The security of this relies on UI-Auth sessions only being used for the same +request as they were initiated for. It is not believed that this is currently +enforced. ## Unstable prefix -We should use a vendor prefix here until this hits the spec. - -`org.matrix.login.sso` ? \ No newline at end of file +A vendor prefix of `org.matrix.login.sso` (instead of `m.login.sso` is proposed +until this is part of the specification. From 4d177753e1e8043b92f9bcec0c4501b9a2802a63 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 15:05:37 -0400 Subject: [PATCH 28/79] Move proposal to proper proposal number. --- ...active-auth-for-sso.md => 2454-ui-interactive-auth-for-sso.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{xxxx-ui-interactive-auth-for-sso.md => 2454-ui-interactive-auth-for-sso.md} (100%) diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md similarity index 100% rename from proposals/xxxx-ui-interactive-auth-for-sso.md rename to proposals/2454-ui-interactive-auth-for-sso.md From 570398e045476fcf4e289367d4856d44b0882b67 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 10 Mar 2020 10:00:58 -0400 Subject: [PATCH 29/79] Remove section on the how the authentication currently works and just reference the specification. --- proposals/2454-ui-interactive-auth-for-sso.md | 65 +------------------ 1 file changed, 1 insertion(+), 64 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index 5b6f396d..bfad25a9 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -11,75 +11,12 @@ system, the user doesn't have a password registered with the homeserver. Instead we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to -[user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). +[user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). In theory, any clients that already implement the fallback process for unknown authentication types will work fine without modification. It is unknown whether this is widely supported among clients. -### UI Auth Overview - -When the client calls one of the protected endpoints, it initially returns a 401 -response. For example: - -``` -POST /_matrix/client/r0/delete_devices HTTP/1.1 -Content-Type: application/json - -{ - "devices": ["FSVVTZRRAA"] -} - -HTTP/1.1 401 Unauthorized -Content-Type: application/json - -{ - "flows": [ - { - "stages": [ - "m.login.password" - ] - } - ], - "params": {}, - "session": "dTKfsLHSAJeAhqfxUsvrIVJd" -} -``` - -The client: - -* inspects the "flows" list -* discovers there is a flow it knows how to follow -* carries out the first "stage" of that flow (m.login.password) - -In this example, the client prompts the user to enter a password. - -The client then resubmits with an additional 'auth' param, with "type" giving -the name of the authentication type it has just carried out. That completes the -authentication flow, so the server is now happy, and returns a 200: - -``` -POST /_matrix/client/r0/delete_devices HTTP/1.1 -Content-Type: application/json - -{ - "devices": ["FSVVTZRRAA"], - "auth": { - "session":"dTKfsLHSAJeAhqfxUsvrIVJd", - "type":"m.login.password", - "identifier":{"type":"m.id.user", "user":"@userid:matrix.org"}, - "password":"" - } -} - - -HTTP/1.1 200 OK -Content-Type: application/json -Content-Length: 179 - -{} -``` - ## Proposal We add an `m.login.sso` authentication type to the UI auth spec. There are no From 78e08c1987460cd14eba27f503b95b6dc4083a29 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 10 Mar 2020 10:11:08 -0400 Subject: [PATCH 30/79] Attempt to clarify the proposed changes. --- proposals/2454-ui-interactive-auth-for-sso.md | 38 +++++++++++-------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index bfad25a9..d3cab51b 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -1,4 +1,4 @@ -# User-Interactive Auth for SSO-backed homeserver +# User-Interactive Authentication for SSO-backed homeserver Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and `POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their @@ -10,17 +10,21 @@ password. However, on a homeserver where users authenticate via a single-sign-on system, the user doesn't have a password registered with the homeserver. Instead we need to delegate that check to the SSO system. -At the protocol level, this means adding support for SSO to +At the protocol level, this means adding support for SSO to the [user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -In theory, any clients that already implement the fallback process for unknown -authentication types will work fine without modification. It is unknown whether -this is widely supported among clients. +In theory, once SSO is added as a possible flow for authentication any clients +that already implement the [fallback process for unknown authentication types](https://matrix.org/docs/spec/client_server/r0.6.0#fallback) +will work fine without modification. It is unknown whether this is widely +supported among clients. ## Proposal -We add an `m.login.sso` authentication type to the UI auth spec. There are no -additional params as part of this auth type. +An [additional authentication type](https://matrix.org/docs/spec/client_server/r0.6.0#authentication-types) +of `m.login.sso` is added to the user-interactive authentication specification. +There are no additional parameters as part of this authentication type. + +When choosing this authentication flow, the following should occur: 1. If the client wants to complete that authentication type, it opens a browser window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` @@ -91,8 +95,9 @@ limited by the chosen SSO implementation, for example: HTTP/1.1 200 OK - can delete device pls? - clicky + A client is trying to remove a device from your account. To confirm this + action, re-authenticate with single sign-on. + If you did not expect this, your account may be compromised! ``` @@ -101,11 +106,12 @@ limited by the chosen SSO implementation, for example: ``` GET https://sso_provider/validate?SAMLRequest= HTTP/1.1 - ... SAML/CAS stuff + ``` 3. The SSO provider validates the user and ends up redirecting the browser back - to the homeserver. (The example below shows a 302 for simplicity but SAML normally uses a 200 with an html , with javascript to automatically submit it.) + to the homeserver. The example below shows a 302 for simplicity, this might + vary based on SSO implementation. ``` HTTP/1.1 302 Moved @@ -191,13 +197,13 @@ change to your account. This problem can be mitigated by clearly telling the user what is about to happen. -### Reusing UI-Auth sessions +### Reusing User Interactive Authentication sessions -The security of this relies on UI-Auth sessions only being used for the same -request as they were initiated for. It is not believed that this is currently -enforced. +The security of this relies on User Interactive Authentication sessions only +being used for the same request as they were initiated for. It is not believed +that this is currently enforced. ## Unstable prefix -A vendor prefix of `org.matrix.login.sso` (instead of `m.login.sso` is proposed +A vendor prefix of `org.matrix.login.sso` is proposed (instead of `m.login.sso`) until this is part of the specification. From 1facf7ff12834ad06fcaff9ee5e2cdf9d1302837 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Thu, 12 Mar 2020 14:14:20 -0400 Subject: [PATCH 31/79] Add an MSC proposal for how to handle sessions when modifying a password. --- ...sword-modification-invalidating-devices.md | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 proposals/2457-password-modification-invalidating-devices.md diff --git a/proposals/2457-password-modification-invalidating-devices.md b/proposals/2457-password-modification-invalidating-devices.md new file mode 100644 index 00000000..910e7b62 --- /dev/null +++ b/proposals/2457-password-modification-invalidating-devices.md @@ -0,0 +1,53 @@ +# Invalidating devices during password modification + +There are multiple use cases for why a user might want to modify their password: + +* Adopting a password manager (to use a unique password or more secure password). +* Password rotation. +* Re-secure a compromised account. +* ... probably tons of others ... + +These can be summarized into two groups: + +1. "My account has been compromised and I need to re-secure it." +2. "I just want to change my password." + +The [current Matrix specification](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password) +does not provide a way to differentiate between these use cases. It gives no +guidance into what should happen to other sessions / devices when a password is +modified and leaves it up to the implementation. + +It is reasonable for a client to want to specify this behavior to offer two +different workflows: + +1. Modify a password and log all other devices out (for use when an account has + been compromised). +2. Modify a password and do not touch any session data (for use in a + non-malicious situations). + +Alternately a client may default to whichever workflow is best for their users. + +## Proposal + +An optional field is added to the JSON body body of the [password reset endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password) +called `logout_devices`. This is a boolean flag (defaulting to `true`) that +signals to whether other devices and sessions should be invalidated after +modifying the password. + +## Potential issues + +While Synapse defaults to the behavior of invalidating other devices and +sessions this may not be true of other implementations. Thus, a default of +`true` may not be backwards compatible. It might be more prudent to specify that +the behavior of not specifying the `logout_devices` flag is undefined. + +## Alternatives + +Provide a new endpoint in a future version that supports an additional field (as +above), using a new endpoint would avoid backwards compatibility issues. + +## Security considerations + +By defaulting to invalidating devices and sessions the security considerations +of this endpoint should remain intact. A client will need to be modified to +choose to keep other devices active. From 61b306f8a8a63005f2ab131d32cbf1d5409ddada Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 13 Mar 2020 07:12:57 -0400 Subject: [PATCH 32/79] Remove concerns about backwards compatibility. --- ...-password-modification-invalidating-devices.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/proposals/2457-password-modification-invalidating-devices.md b/proposals/2457-password-modification-invalidating-devices.md index 910e7b62..9af6e229 100644 --- a/proposals/2457-password-modification-invalidating-devices.md +++ b/proposals/2457-password-modification-invalidating-devices.md @@ -36,15 +36,18 @@ modifying the password. ## Potential issues -While Synapse defaults to the behavior of invalidating other devices and -sessions this may not be true of other implementations. Thus, a default of -`true` may not be backwards compatible. It might be more prudent to specify that -the behavior of not specifying the `logout_devices` flag is undefined. +The specification states: + +> The homeserver SHOULD NOT revoke the access token provided in the request, +> however all other access tokens for the user should be revoked if the request +> succeeds. + +Defaulting `logout_devices` to `true` should be backwards compatible. ## Alternatives -Provide a new endpoint in a future version that supports an additional field (as -above), using a new endpoint would avoid backwards compatibility issues. +A new endpoint could be provided in a future version of the specification that +supports an additional field (as described above). ## Security considerations From 2d2731efff99ddeb67bdb16a716ed1eba8660189 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 16 Mar 2020 10:42:17 -0400 Subject: [PATCH 33/79] Remove duplicated word. Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/2457-password-modification-invalidating-devices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2457-password-modification-invalidating-devices.md b/proposals/2457-password-modification-invalidating-devices.md index 9af6e229..9b59156c 100644 --- a/proposals/2457-password-modification-invalidating-devices.md +++ b/proposals/2457-password-modification-invalidating-devices.md @@ -29,7 +29,7 @@ Alternately a client may default to whichever workflow is best for their users. ## Proposal -An optional field is added to the JSON body body of the [password reset endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password) +An optional field is added to the JSON body of the [password reset endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password) called `logout_devices`. This is a boolean flag (defaulting to `true`) that signals to whether other devices and sessions should be invalidated after modifying the password. From 7917d087f3874f07cfaf0750ed493ded95bc77ac Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 19 Mar 2020 15:21:50 +0000 Subject: [PATCH 34/79] clarifications --- proposals/2432-revised-alias-publishing.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md index dff72df5..4c2f010f 100644 --- a/proposals/2432-revised-alias-publishing.md +++ b/proposals/2432-revised-alias-publishing.md @@ -96,8 +96,16 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and (Note: Synapse currently implements this check on the main alias, though this is unspecced.) - (TODO: what error code should be returned if the alias is invalid, or if it - points to the wrong room?) + The following error codes are specified: + + * HTTP 400, with `errcode: M_INVALID_PARAMETER` if an attempt is made to add + an entry which is not a well-formed alias (examples: too long, doesn't + start with `#`, doesn't contain a `:`). + + * HTTP 400, with `errcode: M_BAD_ALIAS` if an added alias does not point at + the given room (either because the alias doesn't exist, because it can't + be resolved due to an unreachable server, or because the alias points at a + different room). * Currently, [`PUT /_matrix/client/r0/directory/room/{roomAlias}`](https://matrix.org/docs/spec/client_server/r0.6.0#put-matrix-client-r0-directory-room-roomalias) attempts to send updated `m.room.aliases` events on the caller's @@ -110,8 +118,14 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and deleted. (Again, this is implemented in Synapse but does not appear to be explicitly specced.) The `m.room.aliases` functionality should be removed, and the `m.room.canonical_alias` functionality should be extended to cover - `alt_aliases`. As today, no error occurs if the caller does not have - permission to send such an event. + `alt_aliases`. + + The behaviour if the calling user has permission to delete the alias but + does not have permission to send `m.room.canonical_alias` events in the room + (for example, by virtue of being a "server administrator", or by being the + user that created the alias) is implementation-defined. It is *recommended* + that in this case, the alias is deleted anyway, and a successful response is + returned to the client. * A new api endpoint, `GET /_matrix/client/r0/rooms/{roomId}/aliases` is added, which returns the list of aliases currently defined on the local From 2b71234f3c8cd39da78ae63553d1c97f9d9aed6e Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Thu, 19 Mar 2020 14:39:54 -0400 Subject: [PATCH 35/79] clarify first run of iterative auth checks --- specification/rooms/v2.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specification/rooms/v2.rst b/specification/rooms/v2.rst index 4e8365bf..afc114f8 100644 --- a/specification/rooms/v2.rst +++ b/specification/rooms/v2.rst @@ -148,8 +148,8 @@ The *resolution* of a set of states is obtained as follows: 1. Take all *power events* and any events in their auth chains, recursively, that appear in the *full conflicted set* and order them by the *reverse topological power ordering*. -2. Apply the *iterative auth checks algorithm* on the *unconflicted state map* - and the list of events from the previous step to get a partially resolved +2. Apply the *iterative auth checks algorithm*, starting from the *unconflicted state map*, + to the list of events from the previous step to get a partially resolved state. 3. Take all remaining events that weren't picked in step 1 and order them by the mainline ordering based on the power level in the partially resolved From 28dc6a05153437c76156ea022c7d2a7efe58be04 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Fri, 20 Mar 2020 20:29:44 +0000 Subject: [PATCH 36/79] Update proposals/2422-allow-color-attribute-on-font-tag.md Apply typo fix as suggested. Co-Authored-By: David Vo --- proposals/2422-allow-color-attribute-on-font-tag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2422-allow-color-attribute-on-font-tag.md b/proposals/2422-allow-color-attribute-on-font-tag.md index 11f06bff..4e6a9ced 100644 --- a/proposals/2422-allow-color-attribute-on-font-tag.md +++ b/proposals/2422-allow-color-attribute-on-font-tag.md @@ -36,4 +36,4 @@ Add the `color` attribute to the allowed attributes of `` in section - Add a section to tell the clients to prefer `color` over `mx-data-color` -> I don't really know, why mx-data-* was chosen, but I assume there was a reason, so I don't want to change that. - Spec an entirely different format for messages (that would probably not make this proposal obsolete) - -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is dicouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. + -> This wouldn't fix the issue, where some client may choose to remove the color tag, since it is discouraged in the spec. Migration would probably also take a while, so this proposal is a quick solution, that doesn't prevent other solutions at a later date. From 4d808762da4968594c63068351598dbae7245784 Mon Sep 17 00:00:00 2001 From: Aaron Axvig Date: Mon, 23 Mar 2020 12:11:18 -0400 Subject: [PATCH 37/79] Change formatting from italics to code --- api/client-server/redaction.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/client-server/redaction.yaml b/api/client-server/redaction.yaml index 58141049..907b1d16 100644 --- a/api/client-server/redaction.yaml +++ b/api/client-server/redaction.yaml @@ -37,7 +37,7 @@ paths: This cannot be undone. Users may redact their own events, and any user with a power level - greater than or equal to the `redact` power level of the room may + greater than or equal to the ``redact`` power level of the room may redact events there. operationId: redactEvent security: From fc03f7faa6e1d47ccc8470837beef1f43287929b Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 Mar 2020 12:42:15 -0400 Subject: [PATCH 38/79] Remove query_auth from the specification per MSC2451. --- api/server-server/event_auth.yaml | 134 ---------------------------- specification/server_server_api.rst | 1 - 2 files changed, 135 deletions(-) diff --git a/api/server-server/event_auth.yaml b/api/server-server/event_auth.yaml index 0db0d401..8f545e1d 100644 --- a/api/server-server/event_auth.yaml +++ b/api/server-server/event_auth.yaml @@ -72,137 +72,3 @@ paths: example: $ref: "examples/minimal_pdu.json" required: ['auth_chain'] - "/query_auth/{roomId}/{eventId}": - post: - summary: Compare auth chains with the receiving server - description: |- - Compares the auth chain provided with what the receiving server has for the - room ID and event ID combination. - - The auth difference can be calculated in two parts, where the "remote auth" - is the auth chain provided by the sending server and the "local auth" is the - auth chain the receiving server has. With those lists, the algorithm works - bottom-up after sorting each chain by depth then by event ID. The differences - are then discovered and returned as the response to this API call. - operationId: compareEventAuth - security: - - signedRequest: [] - parameters: - - in: path - name: roomId - type: string - description: The room ID to compare the auth chain in. - required: true - x-example: "!abc123:matrix.org" - - in: path - name: eventId - type: string - description: The event ID to compare the auth chain of. - required: true - x-example: "$helloworld:example.org" - - in: body - name: body - schema: - type: object - properties: - auth_chain: - type: array - description: |- - The auth chain (the "remote auth"). Note that events have a different - format depending on the room version - check the `room version specification`_ - for precise event formats. - items: - type: object - title: PDU - description: |- - The `PDUs <#pdus>`_ contained in the auth chain. The event format - varies depending on the room version - check the `room version specification`_ - for precise event formats. - properties: [] - example: - $ref: "examples/minimal_pdu.json" - missing: - type: array - description: |- - A list of event IDs that the sender thinks the receiver is missing. - items: - type: string - example: [] - rejects: - type: object - description: |- - The set of events that the sending server has rejected from the provided - auth chain. - - The ``string`` key is the event ID that was rejected. - additionalProperties: - type: object - title: Rejection Reason - properties: - reason: - type: enum - enum: ['auth_error', 'replaced', 'not_ancestor'] - description: |- - The reason for the event being rejected. - required: ['reason'] - example: { - "$some_event:example.org": { - "reason": "auth_error" - } - } - required: ['auth_chain'] - responses: - 200: - description: The auth chain differences, as determined by the receiver. - schema: - type: object - properties: - auth_chain: - type: array - description: |- - The auth chain the receiver has, and used to determine the auth - chain differences (the "local auth"). Note that events have a different - format depending on the room version - check the `room version specification`_ - for precise event formats. - items: - type: object - title: PDU - description: |- - The `PDUs <#pdus>`_ contained in the auth chain. The event format - varies depending on the room version - check the `room version specification`_ - for precise event formats. - properties: [] - example: - $ref: "examples/minimal_pdu.json" - missing: - type: array - description: |- - The list of event IDs that the receiver believes it is missing, - after comparing the "remote auth" and "local auth" chains. - items: - type: string - example: ["$a_missing_event:example.org"] - rejects: - type: object - description: |- - The set of events that the receiving server has rejected from the - auth chain, not including events that the sending server is missing - as determined from the difference algorithm. - - The ``string`` key is the event ID that was rejected. - additionalProperties: - type: object - title: Rejection Reason - properties: - reason: - type: enum - enum: ['auth_error', 'replaced', 'not_ancestor'] - description: |- - The reason for the event being rejected. - required: ['reason'] - example: { - "$some_event:example.org": { - "reason": "auth_error" - } - } - required: ['auth_chain', 'missing', 'rejects'] diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index a3a57dbf..f0a9a563 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -1077,7 +1077,6 @@ The following endpoint prefixes MUST be protected: * ``/_matrix/federation/v1/state_ids`` * ``/_matrix/federation/v1/backfill`` * ``/_matrix/federation/v1/event_auth`` -* ``/_matrix/federation/v1/query_auth`` * ``/_matrix/federation/v1/get_missing_events`` From 9944decacfe58c0a635b34bd30bdf8f3e4a73329 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 Mar 2020 13:17:22 -0400 Subject: [PATCH 39/79] Add changelog entry. --- changelogs/server_server/newsfragments/2470.removal | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/server_server/newsfragments/2470.removal diff --git a/changelogs/server_server/newsfragments/2470.removal b/changelogs/server_server/newsfragments/2470.removal new file mode 100644 index 00000000..3221f5bf --- /dev/null +++ b/changelogs/server_server/newsfragments/2470.removal @@ -0,0 +1 @@ +Remove the unused ``query_auth`` API per [MSC2451](https://github.com/matrix-org/matrix-doc/pull/2451). From 4f0ac741a2350a46231d320cf310718339d14a2d Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 24 Mar 2020 11:22:05 -0600 Subject: [PATCH 40/79] Update changelogs/server_server/newsfragments/2470.removal --- changelogs/server_server/newsfragments/2470.removal | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs/server_server/newsfragments/2470.removal b/changelogs/server_server/newsfragments/2470.removal index 3221f5bf..51cdadd4 100644 --- a/changelogs/server_server/newsfragments/2470.removal +++ b/changelogs/server_server/newsfragments/2470.removal @@ -1 +1 @@ -Remove the unused ``query_auth`` API per [MSC2451](https://github.com/matrix-org/matrix-doc/pull/2451). +Remove the unused ``query_auth`` API per `MSC2451 `_. From f7ce75d36c2dc09b24cba7c6c8fcdd419992e659 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 24 Mar 2020 11:29:00 -0600 Subject: [PATCH 41/79] Support a 'removed endpoints' changelog type --- changelogs/README.md | 19 ++++++++++++------- changelogs/application_service/pyproject.toml | 15 ++++++++++----- changelogs/client_server/pyproject.toml | 15 ++++++++++----- changelogs/identity_service/pyproject.toml | 5 +++++ changelogs/push_gateway/pyproject.toml | 15 ++++++++++----- changelogs/server_server/pyproject.toml | 15 ++++++++++----- 6 files changed, 57 insertions(+), 27 deletions(-) diff --git a/changelogs/README.md b/changelogs/README.md index a5fb1fb7..5a5b6271 100644 --- a/changelogs/README.md +++ b/changelogs/README.md @@ -2,14 +2,14 @@ # Changelogs -[Towncrier](https://github.com/hawkowl/towncrier) is used to manage the changelog and +[Towncrier](https://github.com/hawkowl/towncrier) is used to manage the changelog and keep it up to date. Because of this, updating a changelog is really easy. ## How to update a changelog when releasing an API 1. Ensure you're in your Python 3 virtual environment 2. `cd` your way to the API you're releasing (eg: `cd changelogs/client_server`) -3. Run `towncrier --version "r0.4.0" --name "client-server" --yes` substituting the +3. Run `towncrier --version "r0.4.0" --name "client-server" --yes` substituting the variables as approprite. Note that `--name` is required although the value is ignored. 4. Commit the changes and finish the release process. @@ -26,27 +26,32 @@ For this example, we're going to pretend that the `server_server` API doesn't ex directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/application_service/pyproject.toml b/changelogs/application_service/pyproject.toml index 44d430e8..278def78 100644 --- a/changelogs/application_service/pyproject.toml +++ b/changelogs/application_service/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/client_server/pyproject.toml b/changelogs/client_server/pyproject.toml index 8fa3f6b5..eb9e7b4e 100644 --- a/changelogs/client_server/pyproject.toml +++ b/changelogs/client_server/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/identity_service/pyproject.toml b/changelogs/identity_service/pyproject.toml index a7fe582d..2e50b9df 100644 --- a/changelogs/identity_service/pyproject.toml +++ b/changelogs/identity_service/pyproject.toml @@ -19,6 +19,11 @@ name = "New Endpoints" showcontent = true + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" diff --git a/changelogs/push_gateway/pyproject.toml b/changelogs/push_gateway/pyproject.toml index dad1bc04..9f2595c9 100644 --- a/changelogs/push_gateway/pyproject.toml +++ b/changelogs/push_gateway/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" diff --git a/changelogs/server_server/pyproject.toml b/changelogs/server_server/pyproject.toml index 98478527..6a9dca1d 100644 --- a/changelogs/server_server/pyproject.toml +++ b/changelogs/server_server/pyproject.toml @@ -3,27 +3,32 @@ directory = "newsfragments" issue_format = "`#{issue} `_" title_format = "{version}" - + [[tool.towncrier.type]] directory = "breaking" name = "Breaking Changes" showcontent = true - + [[tool.towncrier.type]] directory = "deprecation" name = "Deprecations" showcontent = true - + [[tool.towncrier.type]] directory = "new" name = "New Endpoints" showcontent = true - + + [[tool.towncrier.type]] + directory = "removal" + name = "Removed Endpoints" + showcontent = true + [[tool.towncrier.type]] directory = "feature" name = "Backwards Compatible Changes" showcontent = true - + [[tool.towncrier.type]] directory = "clarification" name = "Spec Clarifications" From eb48863c4044105b86d62997d88a086eda22e690 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Thu, 26 Mar 2020 11:47:32 -0400 Subject: [PATCH 42/79] Markdown formatting. Co-Authored-By: Hubert Chathi --- proposals/2454-ui-interactive-auth-for-sso.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index d3cab51b..3532a2fc 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -52,7 +52,7 @@ limited by the chosen SSO implementation, for example: * SAML2 servers typically only support one URL per service provider, so in practice it will need to be the same as that already used for the login flow - (for synapse, it's /_matrix/saml2/authn_response) - and the server needs to + (for synapse, it's `/_matrix/saml2/authn_response`) - and the server needs to be able to figure out if it's doing SSO for a login attempt or an SSO attempt. * CAS doesn't have the same restriction. From 745f8c09df6f948f9083449b2b0848444776855e Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 27 Mar 2020 13:59:37 -0400 Subject: [PATCH 43/79] Fix incorrect statement about the current spec's guidance. --- .../2457-password-modification-invalidating-devices.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2457-password-modification-invalidating-devices.md b/proposals/2457-password-modification-invalidating-devices.md index 9b59156c..ccde2ac6 100644 --- a/proposals/2457-password-modification-invalidating-devices.md +++ b/proposals/2457-password-modification-invalidating-devices.md @@ -13,9 +13,9 @@ These can be summarized into two groups: 2. "I just want to change my password." The [current Matrix specification](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password) -does not provide a way to differentiate between these use cases. It gives no -guidance into what should happen to other sessions / devices when a password is -modified and leaves it up to the implementation. +does not provide a way to differentiate between these use cases. It currently +specifies behavior that fits well into the first use-case above: that the +sessions except the current session should be revoked. It is reasonable for a client to want to specify this behavior to offer two different workflows: From edd75703e2e51eab8ccf611a01486eb26e6929e9 Mon Sep 17 00:00:00 2001 From: Aaron Axvig Date: Sat, 28 Mar 2020 18:32:53 -0400 Subject: [PATCH 44/79] Improved steps for building docs on Windows --- README.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/README.rst b/README.rst index ace8ebdd..d7b75876 100644 --- a/README.rst +++ b/README.rst @@ -66,6 +66,8 @@ The above will write the rendered version of the specification to Windows users ~~~~~~~~~~~~~ +The ``source`` program does not exist on Windows, so instead run one of the +``activate`` files in ``.\env\Scripts\`` to activate the virtual environment. If you're on Windows Vista or higher, be sure that the "Symbolic Links" option was selected when installing Git prior to cloning this repository. If @@ -81,6 +83,24 @@ cloned matrix-doc directory and run the following:: This will delete the file and replace it with a symlink. Git should not detect this as a change, and you should be able to go back to building the project. +Powershell doesn't have ``mklink`` so use cmd. Or, here is the full set of +steps for Powershell: + +.. code-block:: powershell + + virtualenv -p python3 env + .\env\Scripts\pip.exe install -r .\scripts\requirements.txt + + .\env\Scripts\activate.ps1 # Adds a global function 'deactivate' for leaving the env when you are done. + .\Scripts\gendoc.py + + # If you get errors: + cd api\client-server\definitions + del event-schemas + New-Item -ItemType SymbolicLink -Name event-schemas -Value "..\..\..\event-schemas" + cd ..\..\..\ + .\scripts\gendoc.py + Generating the OpenAPI (Swagger) specs -------------------------------------- From 2f5d8a4a271982a786ded1b2dc23a02e35c95583 Mon Sep 17 00:00:00 2001 From: aaronaxvig Date: Mon, 30 Mar 2020 14:32:45 -0400 Subject: [PATCH 45/79] Removed PowerShell stuff Clarified to use Command Prompt as recommended is pull request #2479, removed all PowerShell stuff. --- README.rst | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/README.rst b/README.rst index d7b75876..01ea8e72 100644 --- a/README.rst +++ b/README.rst @@ -73,7 +73,7 @@ If you're on Windows Vista or higher, be sure that the "Symbolic Links" option was selected when installing Git prior to cloning this repository. If you're still seeing errors about files not being found it is likely because the symlink at ``api/client-server/definitions/event-schemas`` looks like a -file. To correct the problem, open an Administrative/Elevated shell in your +file. To correct the problem, open an Administrative/Elevated Command Prompt in your cloned matrix-doc directory and run the following:: cd api\client-server\definitions @@ -83,24 +83,6 @@ cloned matrix-doc directory and run the following:: This will delete the file and replace it with a symlink. Git should not detect this as a change, and you should be able to go back to building the project. -Powershell doesn't have ``mklink`` so use cmd. Or, here is the full set of -steps for Powershell: - -.. code-block:: powershell - - virtualenv -p python3 env - .\env\Scripts\pip.exe install -r .\scripts\requirements.txt - - .\env\Scripts\activate.ps1 # Adds a global function 'deactivate' for leaving the env when you are done. - .\Scripts\gendoc.py - - # If you get errors: - cd api\client-server\definitions - del event-schemas - New-Item -ItemType SymbolicLink -Name event-schemas -Value "..\..\..\event-schemas" - cd ..\..\..\ - .\scripts\gendoc.py - Generating the OpenAPI (Swagger) specs -------------------------------------- From 4cfcda57fb3676d6de6145bb9bd1f9de60645559 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 1 Apr 2020 10:48:05 -0400 Subject: [PATCH 46/79] Clarify that the only new item here is the new authentication type. --- proposals/2454-ui-interactive-auth-for-sso.md | 31 ++++++++++++++++--- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index 3532a2fc..fff96dcf 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -22,11 +22,27 @@ supported among clients. An [additional authentication type](https://matrix.org/docs/spec/client_server/r0.6.0#authentication-types) of `m.login.sso` is added to the user-interactive authentication specification. -There are no additional parameters as part of this authentication type. + +There are no additional parameters as part of this authentication type. As per +the user-interactive authentication specification the only parameter include in +the `auth` dictionary should be the session ID from the homeserver, e.g.: + +```json +{ + "auth": { + "session": "" + } +} +``` + +### Detailed fallback authentication flow: + +The following is a re-iteration of the [fallback authentication flow](https://matrix.org/docs/spec/client_server/r0.6.0#fallback), +but with details filled in for the proposed new authentication type. When choosing this authentication flow, the following should occur: -1. If the client wants to complete that authentication type, it opens a browser +1. If the client wants to complete authentication using SSO, it opens a browser window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` with session set to the UI-Auth session id (from the "auth" dict). @@ -59,6 +75,10 @@ limited by the chosen SSO implementation, for example: ### Example flow: +A more complete example is provided below in which a user attempts to delete +a device and is pushed into the user interactive authentication process with +SSO being the only possible flow. + 0. Client submits the request, which the server says requires SSO: ``` @@ -163,7 +183,7 @@ limited by the chosen SSO implementation, for example: ## Alternatives An alternative client flow where the fallback auth ends up redirecting to a -given URI, instead of doing JavaScript postMessage foo could be considered. +given URI, instead of doing JavaScript `postMessage` foo could be considered. This is probably an orthogonal change to the fallback auth though. ## Security considerations @@ -200,8 +220,9 @@ This problem can be mitigated by clearly telling the user what is about to happe ### Reusing User Interactive Authentication sessions The security of this relies on User Interactive Authentication sessions only -being used for the same request as they were initiated for. It is not believed -that this is currently enforced. +being used for the same request as they were initiated for. This security is not +only a concern for the proposed SSO authentication type. It is not believed +that this is currently enforced in implementations. ## Unstable prefix From 5ae8a8bcfd563ef0d472d0560beba53798897e3c Mon Sep 17 00:00:00 2001 From: Ben Parsons Date: Tue, 7 Apr 2020 14:37:55 +0100 Subject: [PATCH 47/79] fix pagination in scraper --- scripts/proposals.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/proposals.py b/scripts/proposals.py index 27cc6cfb..96904ce4 100755 --- a/scripts/proposals.py +++ b/scripts/proposals.py @@ -38,7 +38,7 @@ def getpage(url): pagecount = 1 for link in resp.links.values(): if link['rel'] == 'last': - pagecount = int(re.search('page=(.+?)', link['url']).group(1)) + pagecount = int(re.search('page=(.+)', link['url']).group(1)) val = resp.json() if not isinstance(val, list): From 7c037d2490203d156e9def41f43ce255d863d48b Mon Sep 17 00:00:00 2001 From: Ben Parsons Date: Tue, 7 Apr 2020 15:26:48 +0100 Subject: [PATCH 48/79] improve capture and add example --- scripts/proposals.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/proposals.py b/scripts/proposals.py index 96904ce4..faa10a83 100755 --- a/scripts/proposals.py +++ b/scripts/proposals.py @@ -38,7 +38,10 @@ def getpage(url): pagecount = 1 for link in resp.links.values(): if link['rel'] == 'last': - pagecount = int(re.search('page=(.+)', link['url']).group(1)) + # we extract the pagecount from the `page` param of the last url + # in the response, eg + # 'https://api.github.com/repositories/24998719/issues?state=all&labels=proposal&page=10' + pagecount = int(re.search('page=(\d+)', link['url']).group(1)) val = resp.json() if not isinstance(val, list): From af7cf84083cf17de938102bfac1951caebc89c3e Mon Sep 17 00:00:00 2001 From: Lukas Lihotzki Date: Tue, 7 Apr 2020 17:54:09 +0200 Subject: [PATCH 49/79] Fix iv parameter description Signed-off-by: Lukas Lihotzki --- specification/modules/end_to_end_encryption.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/modules/end_to_end_encryption.rst b/specification/modules/end_to_end_encryption.rst index 631b182a..4b433f17 100644 --- a/specification/modules/end_to_end_encryption.rst +++ b/specification/modules/end_to_end_encryption.rst @@ -277,7 +277,7 @@ Parameter Type Description ========= ================ ===================================================== url string **Required.** The URL to the file. key JWK **Required.** A `JSON Web Key`_ object. -iv string **Required.** The Initialisation Vector used by +iv string **Required.** The 128-bit unique counter block used by AES-CTR, encoded as unpadded base64. hashes {string: string} **Required.** A map from an algorithm name to a hash of the ciphertext, encoded as unpadded base64. Clients From b908b8e777840741587d22c6c1bbf25f69ecaeab Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 7 Apr 2020 13:13:52 -0600 Subject: [PATCH 50/79] Add changelog --- changelogs/client_server/newsfragments/2492.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2492.clarification diff --git a/changelogs/client_server/newsfragments/2492.clarification b/changelogs/client_server/newsfragments/2492.clarification new file mode 100644 index 00000000..88c478ec --- /dev/null +++ b/changelogs/client_server/newsfragments/2492.clarification @@ -0,0 +1 @@ +Clarify the IV data type for encrypted files. From f6879c897bace91ccfe0cb102f490e9dc5619cde Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 15 Apr 2020 07:39:00 -0400 Subject: [PATCH 51/79] Fix minor grammatical fixes. Co-Authored-By: Hubert Chathi --- proposals/2454-ui-interactive-auth-for-sso.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index fff96dcf..e39facfb 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -13,7 +13,7 @@ we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to the [user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -In theory, once SSO is added as a possible flow for authentication any clients +In theory, once SSO is added as a possible flow for authentication, any clients that already implement the [fallback process for unknown authentication types](https://matrix.org/docs/spec/client_server/r0.6.0#fallback) will work fine without modification. It is unknown whether this is widely supported among clients. @@ -24,7 +24,7 @@ An [additional authentication type](https://matrix.org/docs/spec/client_server/r of `m.login.sso` is added to the user-interactive authentication specification. There are no additional parameters as part of this authentication type. As per -the user-interactive authentication specification the only parameter include in +the user-interactive authentication specification, the only parameter included in the `auth` dictionary should be the session ID from the homeserver, e.g.: ```json @@ -57,7 +57,7 @@ When choosing this authentication flow, the following should occur: 3. The SSO provider validates the user, and redirects the browser back to the homeserver. 4. The homeserver validates the response from the SSO provider, updates the - user-interactive auth session to show that the SSO has completed, + user-interactive auth session to show that the SSO has completed, and [serves the fallback auth completion page as specced](https://matrix.org/docs/spec/client_server/r0.6.0#fallback). 5. The client resubmits its original request, with its original session id, which now should complete. From 9103a0a3980192f78d65f2f9c08f8e6a5d3e726b Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Thu, 16 Apr 2020 14:58:27 -0400 Subject: [PATCH 52/79] minor clarifications and corrections --- proposals/1756-cross-signing.md | 4 ++-- proposals/1946-secure_server-side_storage.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/1756-cross-signing.md b/proposals/1756-cross-signing.md index 4b5904bc..de08422a 100644 --- a/proposals/1756-cross-signing.md +++ b/proposals/1756-cross-signing.md @@ -216,7 +216,7 @@ response: } ``` -Similarly, the federation endpoints `POST /user/keys/query` and `POST +Similarly, the federation endpoints `POST /user/keys/query` and `GET /user/devices/{userId}` will include the master and self-signing keys. (It will not include the user-signing key because it is not intended to be visible to other users.) @@ -463,7 +463,7 @@ response: } ``` -Similarly, the federation endpoints `GET /user/keys/query` and `POST +Similarly, the federation endpoints `POST /user/keys/query` and `GET /user/devices/{userId}` will include the new signatures for her own devices or master key, but not signatures made by her user-signing key. diff --git a/proposals/1946-secure_server-side_storage.md b/proposals/1946-secure_server-side_storage.md index fd907e53..3f386d5e 100644 --- a/proposals/1946-secure_server-side_storage.md +++ b/proposals/1946-secure_server-side_storage.md @@ -66,7 +66,7 @@ corresponds to the public key. Encrypted data is stored in the user's account_data using the event type defined by the feature that uses the data. For example, decryption keys for -key backups could be stored under the type `m.megolm_backup.v1.recovery_key`, +key backups could be stored under the type `m.megolm_backup.v1`, or the self-signing key for cross-signing could be stored under the type `m.cross_signing.self_signing`. From 3c34d83082f445ea7f5bd80720f87bf2fa749721 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 22 Apr 2020 13:37:50 -0600 Subject: [PATCH 53/79] Add some words about what categories are --- specification/proposals_intro.rst | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 82a4225b..47cb58fc 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -341,6 +341,35 @@ Closed proposal-closed A proposal which Obsolete obsolete A proposal which has been made obsolete by another proposal or decision elsewhere. =============================== ============================= ==================================== +Categories +---------- + +We use category labels on MSCs to place them into a track of work. The spec core team +decides which of the tracks they are focusing on for the next while and generally makes +an effort to pull MSCs out of that category when possible. + +The current categories are: + +============ ================= ====================================== +Name Github Label Description +============ ================= ====================================== +Core kind:core Important for the protocol's success. +Feature kind:feature Nice to have additions to the spec. +Maintenance kind:maintenance Fixes or clarifies existing spec. +============ ================= ====================================== + +Some examples of core MSCs would be aggregations, cross-signing, and groups/communities. +These are the sorts of things that if not implemented could cause the protocol to +fail or become second-class. Features would be areas like enhanced media APIs, +new transports, and bookmarks in comparison. Finally, maintenance MSCs would include +improving error codes, clarifying what is required of an API, and adding properties +to an API which makes it easier to use. + +The spec core team assigns a category to each MSC based on the descriptions above. +This can mean that new MSCs get categorized into an area the team isn't focused on, +though that can always change as priorities evolve. We still encourage that MSCs be +opened, even if not the focus for the time being, as they can still make progress and +even be merged without the spec core team focusing on them specifically. Proposal Tracking ----------------- From b5868a59d64e30829ee28ae19f773a565399846f Mon Sep 17 00:00:00 2001 From: Rudi Floren Date: Wed, 22 Apr 2020 22:18:28 +0200 Subject: [PATCH 54/79] Fix typo in Fed. API request auth python example Fixes the typo in the Request Authentication python example. It seems like a copy paste error. Closes: #2509 Signed-off-by: Rudi Floren --- specification/server_server_api.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index f0a9a563..655a8cfc 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -316,8 +316,8 @@ Example python code: "destination": destination_name, } - if content_json is not None: - request["content"] = content + if content is not None: + request_json["content"] = content signed_json = sign_json(request_json, origin_name, origin_signing_key) From 2bc798dcfa9cebed32c31c5083b365d59efadefc Mon Sep 17 00:00:00 2001 From: Rudi Floren Date: Wed, 22 Apr 2020 22:21:36 +0200 Subject: [PATCH 55/79] Add changelog newsfragment --- changelogs/server_server/newsfragments/2510 | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/server_server/newsfragments/2510 diff --git a/changelogs/server_server/newsfragments/2510 b/changelogs/server_server/newsfragments/2510 new file mode 100644 index 00000000..c9cf10be --- /dev/null +++ b/changelogs/server_server/newsfragments/2510 @@ -0,0 +1 @@ +Fix typo in Request Authentication python example From 97b23da9f6fd52368bee002102f7de9f8e246cdd Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 22 Apr 2020 14:27:22 -0600 Subject: [PATCH 56/79] Update changelog entry for 2510 clarification --- changelogs/server_server/newsfragments/2510 | 1 - changelogs/server_server/newsfragments/2510.clarification | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) delete mode 100644 changelogs/server_server/newsfragments/2510 create mode 100644 changelogs/server_server/newsfragments/2510.clarification diff --git a/changelogs/server_server/newsfragments/2510 b/changelogs/server_server/newsfragments/2510 deleted file mode 100644 index c9cf10be..00000000 --- a/changelogs/server_server/newsfragments/2510 +++ /dev/null @@ -1 +0,0 @@ -Fix typo in Request Authentication python example diff --git a/changelogs/server_server/newsfragments/2510.clarification b/changelogs/server_server/newsfragments/2510.clarification new file mode 100644 index 00000000..9c96c5a5 --- /dev/null +++ b/changelogs/server_server/newsfragments/2510.clarification @@ -0,0 +1 @@ +Fix typo in Request Authentication python example. From 16905a2f5bf3cea32ee0567b8bfd4883d64bccc6 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 22 Apr 2020 14:31:34 -0600 Subject: [PATCH 57/79] Make the spec core team the Spec Core Team --- specification/proposals_intro.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 47cb58fc..771d2d6a 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -344,7 +344,7 @@ Obsolete obsolete A proposal which Categories ---------- -We use category labels on MSCs to place them into a track of work. The spec core team +We use category labels on MSCs to place them into a track of work. The Spec Core Team decides which of the tracks they are focusing on for the next while and generally makes an effort to pull MSCs out of that category when possible. @@ -365,11 +365,11 @@ new transports, and bookmarks in comparison. Finally, maintenance MSCs would inc improving error codes, clarifying what is required of an API, and adding properties to an API which makes it easier to use. -The spec core team assigns a category to each MSC based on the descriptions above. +The Spec Core Team assigns a category to each MSC based on the descriptions above. This can mean that new MSCs get categorized into an area the team isn't focused on, though that can always change as priorities evolve. We still encourage that MSCs be opened, even if not the focus for the time being, as they can still make progress and -even be merged without the spec core team focusing on them specifically. +even be merged without the Spec Core Team focusing on them specifically. Proposal Tracking ----------------- From 0ae597626af258c133ac285220754ccbd663bae6 Mon Sep 17 00:00:00 2001 From: David Vo Date: Fri, 1 May 2020 00:32:15 +1000 Subject: [PATCH 58/79] Fix .m.rule.contains_user_name push rule to highlight Signed-off-by: David Vo --- specification/modules/push.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/specification/modules/push.rst b/specification/modules/push.rst index c9489987..ebf1aef2 100644 --- a/specification/modules/push.rst +++ b/specification/modules/push.rst @@ -473,6 +473,9 @@ Definition (as a ``content`` rule): { "set_tweak": "sound", "value": "default" + }, + { + "set_tweak": "highlight" } ] } From b8efb5ac4701554c5eda7ca7ba3a8f2a880c93b5 Mon Sep 17 00:00:00 2001 From: David Vo Date: Fri, 1 May 2020 15:27:20 +1000 Subject: [PATCH 59/79] Add changelog for 2519 Signed-off-by: David Vo --- changelogs/client_server/newsfragments/2519.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2519.clarification diff --git a/changelogs/client_server/newsfragments/2519.clarification b/changelogs/client_server/newsfragments/2519.clarification new file mode 100644 index 00000000..eb3fb6a8 --- /dev/null +++ b/changelogs/client_server/newsfragments/2519.clarification @@ -0,0 +1 @@ +Fix the ``.m.rule.contains_user_name`` default push rule to set the highlight tweak, matching Synapse and users' expectations. From 411b3f432b57e9f1f6d3a170cd159020fb26bd74 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 1 May 2020 10:25:47 -0600 Subject: [PATCH 60/79] Update changelog --- changelogs/client_server/newsfragments/2519.clarification | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs/client_server/newsfragments/2519.clarification b/changelogs/client_server/newsfragments/2519.clarification index eb3fb6a8..4b32da1e 100644 --- a/changelogs/client_server/newsfragments/2519.clarification +++ b/changelogs/client_server/newsfragments/2519.clarification @@ -1 +1 @@ -Fix the ``.m.rule.contains_user_name`` default push rule to set the highlight tweak, matching Synapse and users' expectations. +Fix the ``.m.rule.contains_user_name`` default push rule to set the highlight tweak. From 958e1b4a2e2ffd7dd4210818daf88385325ac0c4 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 4 May 2020 14:36:52 -0400 Subject: [PATCH 61/79] Make the spec changes for MSC 2457. --- api/client-server/registration.yaml | 8 ++++++-- changelogs/client_server/newsfragments/2523.feature | 1 + 2 files changed, 7 insertions(+), 2 deletions(-) create mode 100644 changelogs/client_server/newsfragments/2523.feature diff --git a/api/client-server/registration.yaml b/api/client-server/registration.yaml index 8114299e..ecc7a6fa 100644 --- a/api/client-server/registration.yaml +++ b/api/client-server/registration.yaml @@ -328,8 +328,7 @@ paths: The homeserver may change the flows available depending on whether a valid access token is provided. The homeserver SHOULD NOT revoke the - access token provided in the request, however all other access tokens - for the user should be revoked if the request succeeds. + access token provided in the request. security: - accessToken: [] operationId: changePassword @@ -343,6 +342,11 @@ paths: type: string description: The new password for the account. example: "ihatebananas" + logout_devices: + type: boolean + description: |- + Whether other access tokens should be revoked if the request succeeds. Defaults to true. + example: true auth: description: |- Additional authentication information for the user-interactive authentication API. diff --git a/changelogs/client_server/newsfragments/2523.feature b/changelogs/client_server/newsfragments/2523.feature new file mode 100644 index 00000000..6f690ea4 --- /dev/null +++ b/changelogs/client_server/newsfragments/2523.feature @@ -0,0 +1 @@ +Optionally invalidate other access tokens during password modification per `MSC 2457 `_. From 0c582ea8c71658b71e76210d30f2ece5c3ea8644 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 4 May 2020 16:21:19 -0400 Subject: [PATCH 62/79] Apply suggestions from code review Co-authored-by: Travis Ralston --- api/client-server/registration.yaml | 3 ++- changelogs/client_server/newsfragments/2523.feature | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/api/client-server/registration.yaml b/api/client-server/registration.yaml index ecc7a6fa..c3f544c1 100644 --- a/api/client-server/registration.yaml +++ b/api/client-server/registration.yaml @@ -345,7 +345,8 @@ paths: logout_devices: type: boolean description: |- - Whether other access tokens should be revoked if the request succeeds. Defaults to true. + Whether the other access tokens, and their associated devices, for the user should be + revoked if the request succeeds. Defaults to true. example: true auth: description: |- diff --git a/changelogs/client_server/newsfragments/2523.feature b/changelogs/client_server/newsfragments/2523.feature index 6f690ea4..e45d1c2f 100644 --- a/changelogs/client_server/newsfragments/2523.feature +++ b/changelogs/client_server/newsfragments/2523.feature @@ -1 +1 @@ -Optionally invalidate other access tokens during password modification per `MSC 2457 `_. +Optionally invalidate other access tokens during password modification per `MSC2457 `_. From 1e330c942307259ffdf076940ca70b7ba33da83e Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 4 May 2020 16:23:31 -0400 Subject: [PATCH 63/79] Clarify revocation behavior. --- api/client-server/registration.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/api/client-server/registration.yaml b/api/client-server/registration.yaml index c3f544c1..50ce4a96 100644 --- a/api/client-server/registration.yaml +++ b/api/client-server/registration.yaml @@ -328,7 +328,8 @@ paths: The homeserver may change the flows available depending on whether a valid access token is provided. The homeserver SHOULD NOT revoke the - access token provided in the request. + access token provided in the request. Whether other access tokens for + the user are revoked depends on the request parameters. security: - accessToken: [] operationId: changePassword From e89521d1951976cb2a3bca9509e5e501b7fd6325 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 4 May 2020 22:08:22 -0400 Subject: [PATCH 64/79] some fixes (spelling, RST, and naming) --- api/client-server/keys.yaml | 2 +- specification/modules/end_to_end_encryption.rst | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/api/client-server/keys.yaml b/api/client-server/keys.yaml index 69e39def..e172ea8a 100644 --- a/api/client-server/keys.yaml +++ b/api/client-server/keys.yaml @@ -101,7 +101,7 @@ paths: responses: 200: description: - The provided keys were sucessfully uploaded. + The provided keys were successfully uploaded. schema: type: object properties: diff --git a/specification/modules/end_to_end_encryption.rst b/specification/modules/end_to_end_encryption.rst index 4b433f17..0223d9f5 100644 --- a/specification/modules/end_to_end_encryption.rst +++ b/specification/modules/end_to_end_encryption.rst @@ -565,9 +565,9 @@ The process between Alice and Bob verifying each other would be: they match or not. #. Assuming they match, Alice and Bob's devices calculate the HMAC of their own device keys and a comma-separated sorted list of of the key IDs that they wish the other user - to verify, using SHA-256 as the hash function. HMAC is defined in [RFC 2104](https://tools.ietf.org/html/rfc2104). + to verify, using SHA-256 as the hash function. HMAC is defined in `RFC 2104 `_. The key for the HMAC is different for each item and is calculated by generating - 32 bytes (256 bits) using `the key verification HKDF <#SAS-HKDF>`_. + 32 bytes (256 bits) using `the key verification HKDF <#sas-hkdf>`_. #. Alice's device sends Bob's device a ``m.key.verification.mac`` message containing the MAC of Alice's device keys and the MAC of her key IDs to be verified. Bob's device does the same for Bob's device keys and key IDs concurrently with Alice. @@ -653,14 +653,14 @@ are used in addition to those already specified: {{m_key_verification_mac_event}} -.. _`SAS-HKDF`: +.. _sas-hkdf: HKDF calculation <<<<<<<<<<<<<<<< -In all of the SAS methods, HKDF is as defined in [RFC 5869](https://tools.ietf.org/html/rfc5869) +In all of the SAS methods, HKDF is as defined in `RFC 5869 `_ and uses the previously agreed-upon hash function for the hash function. The shared -secret is supplied as the input keying material. No salt is used, and the input +secret is supplied as the input keying material. No salt is used, and the info parameter is the concatenation of: * The string ``MATRIX_KEY_VERIFICATION_SAS``. @@ -677,7 +677,7 @@ parameter is the concatenation of: For verification of each party's device keys, HKDF is as defined in RFC 5869 and uses SHA-256 as the hash function. The shared secret is supplied as the input keying -material. No salt is used, and in the input parameter is the concatenation of: +material. No salt is used, and in the info parameter is the concatenation of: * The string ``MATRIX_KEY_VERIFICATION_MAC``. * The Matrix ID of the user whose key is being MAC-ed. @@ -691,7 +691,7 @@ material. No salt is used, and in the input parameter is the concatenation of: SAS method: ``decimal`` <<<<<<<<<<<<<<<<<<<<<<< -Generate 5 bytes using `HKDF <#SAS-HKDF>`_ then take sequences of 13 bits to +Generate 5 bytes using `HKDF <#sas-hkdf>`_ then take sequences of 13 bits to convert to decimal numbers (resulting in 3 numbers between 0 and 8191 inclusive each). Add 1000 to each calculated number. @@ -708,7 +708,7 @@ such as dashes, or with the numbers on individual lines. SAS method: ``emoji`` <<<<<<<<<<<<<<<<<<<<< -Generate 6 bytes using `HKDF <#SAS-HKDF>`_ then split the first 42 bits into +Generate 6 bytes using `HKDF <#sas-hkdf>`_ then split the first 42 bits into 7 groups of 6 bits, similar to how one would base64 encode something. Convert each group of 6 bits to a number and use the following table to get the corresponding emoji: From 6e339542562dfc00c77b2abc91d18b0476f48854 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Damir=20Jeli=C4=87?= Date: Tue, 5 May 2020 12:11:51 +0200 Subject: [PATCH 65/79] client-server: Mark the event_id when putting room events as required. --- api/client-server/room_send.yaml | 2 ++ api/client-server/room_state.yaml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/api/client-server/room_send.yaml b/api/client-server/room_send.yaml index 6963f76c..fc8f3339 100644 --- a/api/client-server/room_send.yaml +++ b/api/client-server/room_send.yaml @@ -85,5 +85,7 @@ paths: type: string description: |- A unique identifier for the event. + required: + - event_id tags: - Room participation diff --git a/api/client-server/room_state.yaml b/api/client-server/room_state.yaml index 62168f26..640e2009 100644 --- a/api/client-server/room_state.yaml +++ b/api/client-server/room_state.yaml @@ -92,6 +92,8 @@ paths: type: string description: |- A unique identifier for the event. + required: + - event_id 403: description: |- The sender doesn't have permission to send the event into the room. From 3054ac572fb518499dd53eb21334788d9d3def68 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Damir=20Jeli=C4=87?= Date: Tue, 5 May 2020 12:17:54 +0200 Subject: [PATCH 66/79] changelogs: Fragment for the event id when putting room events clarification. --- changelogs/client_server/newsfragments/2525.clarification | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 changelogs/client_server/newsfragments/2525.clarification diff --git a/changelogs/client_server/newsfragments/2525.clarification b/changelogs/client_server/newsfragments/2525.clarification new file mode 100644 index 00000000..e93444bf --- /dev/null +++ b/changelogs/client_server/newsfragments/2525.clarification @@ -0,0 +1,2 @@ +Clarification that the event ids are required in the response when putting room +events. From b0e8fd648df7fd9119a0e472710be3e46d3c6483 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 5 May 2020 09:21:58 -0600 Subject: [PATCH 67/79] Apply suggestions from code review --- changelogs/client_server/newsfragments/2525.clarification | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/changelogs/client_server/newsfragments/2525.clarification b/changelogs/client_server/newsfragments/2525.clarification index e93444bf..df1fc538 100644 --- a/changelogs/client_server/newsfragments/2525.clarification +++ b/changelogs/client_server/newsfragments/2525.clarification @@ -1,2 +1 @@ -Clarification that the event ids are required in the response when putting room -events. +Clarify that an ``event_id`` is returned when sending events. From 9980b83dd4bd120a055e8544240121b38cbb628f Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 5 May 2020 15:14:24 -0400 Subject: [PATCH 68/79] add changelog --- changelogs/client_server/newsfragments/2524.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2524.clarification diff --git a/changelogs/client_server/newsfragments/2524.clarification b/changelogs/client_server/newsfragments/2524.clarification new file mode 100644 index 00000000..cf36c3ba --- /dev/null +++ b/changelogs/client_server/newsfragments/2524.clarification @@ -0,0 +1 @@ +Fix various wording and markup issues in the end-to-end encryption section. From 6ede023b35e735f262886d8f02dc3523527443e9 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 5 May 2020 16:06:21 -0400 Subject: [PATCH 69/79] make the changelog match others so they get combined --- changelogs/client_server/newsfragments/2524.clarification | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs/client_server/newsfragments/2524.clarification b/changelogs/client_server/newsfragments/2524.clarification index cf36c3ba..902a9c3f 100644 --- a/changelogs/client_server/newsfragments/2524.clarification +++ b/changelogs/client_server/newsfragments/2524.clarification @@ -1 +1 @@ -Fix various wording and markup issues in the end-to-end encryption section. +Fix various spelling errors throughout the specification. From 6b8b31ce638d82fed94957bb1b6c33bc71fd92cb Mon Sep 17 00:00:00 2001 From: Gnuxie <50846879+Gnuxie@users.noreply.github.com> Date: Wed, 6 May 2020 17:10:39 +0100 Subject: [PATCH 70/79] correct use of required annotation in json-schema https://tools.ietf.org/html/draft-handrews-json-schema-validation-02#section-6.5.3 --- api/server-server/definitions/keys.yaml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/api/server-server/definitions/keys.yaml b/api/server-server/definitions/keys.yaml index 8bc6c563..1e025a52 100644 --- a/api/server-server/definitions/keys.yaml +++ b/api/server-server/definitions/keys.yaml @@ -20,7 +20,6 @@ properties: server_name: type: string description: DNS name of the homeserver. - required: true example: "example.org" verify_keys: type: object @@ -31,7 +30,6 @@ properties: algorithm and ``abc123`` being the version in the example below). Together, this forms the Key ID. The version must have characters matching the regular expression ``[a-zA-Z0-9_]``. - required: true additionalProperties: type: object title: Verify Key @@ -44,8 +42,8 @@ properties: key: type: string description: The `Unpadded Base64`_ encoded key. - required: true example: "VGhpcyBzaG91bGQgYmUgYSByZWFsIGVkMjU1MTkgcGF5bG9hZA" + required: ["key"] old_verify_keys: type: object description: |- @@ -69,13 +67,12 @@ properties: type: integer format: int64 description: POSIX timestamp in milliseconds for when this key expired. - required: true example: 1532645052628 key: type: string description: The `Unpadded Base64`_ encoded key. - required: true example: "VGhpcyBzaG91bGQgYmUgeW91ciBvbGQga2V5J3MgZWQyNTUxOSBwYXlsb2FkLg" + required: ["expired_ts", "key"] signatures: type: object description: Digital signatures for this object signed using the ``verify_keys``. @@ -103,3 +100,4 @@ properties: publishes a key which is valid for a significant amount of time without a way for the homeserver owner to revoke it. example: 1052262000000 +required: ["server_name", "verify_keys"] From 6613cd89a668f400a82a8a9f36b961768d77090f Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Thu, 7 May 2020 15:42:04 +0100 Subject: [PATCH 71/79] 2454-ui-interactive-auth-for-sso.md: markup fix --- proposals/2454-ui-interactive-auth-for-sso.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index e39facfb..18112c5f 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -209,7 +209,7 @@ provider. It's common for SSO providers to redirect straight back to the app if you've recently authenticated with them; even in the best case, the SSO provider shows an innocent message along the lines of "Confirm that you want to sign in to -". +\". After redirecting back to the homeserver, the SSO is completed and the attacker's session is validated. They are now able to make their malicious From 9065d1aa143e06a42fd36e59d923d0756ae6225d Mon Sep 17 00:00:00 2001 From: Ben Parsons Date: Thu, 7 May 2020 15:45:33 +0100 Subject: [PATCH 72/79] proposal to use existing events as captions for images --- proposals/2529-text-messages-as-captions.md | 37 +++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 proposals/2529-text-messages-as-captions.md diff --git a/proposals/2529-text-messages-as-captions.md b/proposals/2529-text-messages-as-captions.md new file mode 100644 index 00000000..df76e325 --- /dev/null +++ b/proposals/2529-text-messages-as-captions.md @@ -0,0 +1,37 @@ +# Use existing m.room.message/m.text events as captions for images + +## Background + +There is a demand to be able to apply a text caption to an image, as is possible in other chat platforms. In Matrix this is not possible, so people will generally send two events: one `m.image`, then a `m.text` event immediately afterward to simulate a caption. + +Better would be to able to explicitly mark an event as a caption. + +## Proposal + +Allow an optional `m.relates_to` field in the `content` field of a text message event. + +Example: + +``` +... + "content": { + "body": "Caption text", + "msgtype": "m.text", + "m.relates_to": { + "event_id": "$(some image event)", + "rel_type": "m.caption" + } + }, +``` + +If a client recognises the `rel_type`, they can render the caption with the image rather than as a separate message in the timeline. + +The benefit of this is that if a client doesn't support or recognise the `m.caption`, it can ignore the relation and just render the message inline. + +This would not require aggregation from the server since there will always be a need to send the event separately anyway. + +## Potential issues + +* Not sure how this relates to the broader questions discussed in MSC1849 +* This is catering to a narrow use-case requirement. There may be a more general solution available +* Would MSC1767 (extensible events) obsolete this? From c704da1449eb18127a4fa4b8028f6dbfb3e1fd9d Mon Sep 17 00:00:00 2001 From: Ben Parsons Date: Thu, 7 May 2020 15:49:18 +0100 Subject: [PATCH 73/79] remove proposal --- proposals/2529-text-messages-as-captions.md | 37 --------------------- 1 file changed, 37 deletions(-) delete mode 100644 proposals/2529-text-messages-as-captions.md diff --git a/proposals/2529-text-messages-as-captions.md b/proposals/2529-text-messages-as-captions.md deleted file mode 100644 index df76e325..00000000 --- a/proposals/2529-text-messages-as-captions.md +++ /dev/null @@ -1,37 +0,0 @@ -# Use existing m.room.message/m.text events as captions for images - -## Background - -There is a demand to be able to apply a text caption to an image, as is possible in other chat platforms. In Matrix this is not possible, so people will generally send two events: one `m.image`, then a `m.text` event immediately afterward to simulate a caption. - -Better would be to able to explicitly mark an event as a caption. - -## Proposal - -Allow an optional `m.relates_to` field in the `content` field of a text message event. - -Example: - -``` -... - "content": { - "body": "Caption text", - "msgtype": "m.text", - "m.relates_to": { - "event_id": "$(some image event)", - "rel_type": "m.caption" - } - }, -``` - -If a client recognises the `rel_type`, they can render the caption with the image rather than as a separate message in the timeline. - -The benefit of this is that if a client doesn't support or recognise the `m.caption`, it can ignore the relation and just render the message inline. - -This would not require aggregation from the server since there will always be a need to send the event separately anyway. - -## Potential issues - -* Not sure how this relates to the broader questions discussed in MSC1849 -* This is catering to a narrow use-case requirement. There may be a more general solution available -* Would MSC1767 (extensible events) obsolete this? From 78f8d1322f220018d51281885ca237a724831366 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 8 May 2020 11:27:11 -0400 Subject: [PATCH 74/79] Add MSC2454 to the specification. --- .../client_server/newsfragments/2532.feature | 1 + specification/client_server_api.rst | 33 +++++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 changelogs/client_server/newsfragments/2532.feature diff --git a/changelogs/client_server/newsfragments/2532.feature b/changelogs/client_server/newsfragments/2532.feature new file mode 100644 index 00000000..cf74a289 --- /dev/null +++ b/changelogs/client_server/newsfragments/2532.feature @@ -0,0 +1 @@ +Add User-Interactive Authentication for SSO-backed homeserver per `MSC2454 `_. diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index eb32d3b4..581f0c28 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -643,6 +643,7 @@ This specification defines the following auth types: - ``m.login.password`` - ``m.login.recaptcha`` - ``m.login.oauth2`` + - ``m.login.sso`` - ``m.login.email.identity`` - ``m.login.msisdn`` - ``m.login.token`` @@ -782,6 +783,38 @@ the auth code. Homeservers can choose any path for the ``redirect URI``. Once the OAuth flow has completed, the client retries the request with the session only, as above. +Single Sign-On +<<<<<<<<<<<<<< +:Type: + ``m.login.sso`` +:Description: + Authentication is supported by authorising with an external single sign-on + provider. + +A client wanting to complete authentication using SSO should use the +`Fallback`_ authentication flow by opening a browser window for +``/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`` with the +session parameter set to the session ID provied by the server. + +The homeserver should return a page which asks for the user's confirmation +before proceeding. For example, the page could say words to the effect of: + + A client is trying to remove a device/add an email address/take over your + account. To confirm this action, re-authenticate with single sign-on. If you + did not expect this, your account may be compromised! + +Once the user has confirmed they should be redirected to the single sign-on +provider's login page. Once the provider has validated the user, the browser is +redirected back to the homeserver. + +The homeserver then validates the response from the single sign-on provider and +updates the user-interactive authentication session to mark the single sign-on +stage has been completed. The browser is shown the fallback authentication +completion page. + +Once the flow has completed, the client retries the request with the session +only, as above. + Email-based (identity / homeserver) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< :Type: From e85f6c31a3f6d2f93de402347edae4500d95b383 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 11 May 2020 15:14:11 -0400 Subject: [PATCH 75/79] Fix a typo found in review. Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- specification/client_server_api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index 581f0c28..fce879a2 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -794,7 +794,7 @@ Single Sign-On A client wanting to complete authentication using SSO should use the `Fallback`_ authentication flow by opening a browser window for ``/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`` with the -session parameter set to the session ID provied by the server. +session parameter set to the session ID provided by the server. The homeserver should return a page which asks for the user's confirmation before proceeding. For example, the page could say words to the effect of: From 3556b8457f5bde619c6e81c9b996c43fc86fb78d Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Mon, 11 May 2020 21:05:26 -0600 Subject: [PATCH 76/79] Add changelog for 2527 --- changelogs/server_server/newsfragments/2527.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/server_server/newsfragments/2527.clarification diff --git a/changelogs/server_server/newsfragments/2527.clarification b/changelogs/server_server/newsfragments/2527.clarification new file mode 100644 index 00000000..329d5da2 --- /dev/null +++ b/changelogs/server_server/newsfragments/2527.clarification @@ -0,0 +1 @@ +Clarify which fields are required on the key server endpoints. From 42ae5c966a1256e3ff2ec1945c45529dc92fae68 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 12 May 2020 19:02:39 -0600 Subject: [PATCH 77/79] Clarify the limits of prev_events and auth_events Fixes https://github.com/matrix-org/matrix-doc/issues/2307 These restrictions are due to a Synapse change which never made it to the spec prior to the MSC process. This is therefore documenting an omission. Synapse's numbers are verified here: https://github.com/matrix-org/synapse/blob/207b1737ee0acd226359d59ce3b7f7d46111b1c8/synapse/handlers/federation.py#L1183-L1213 ... and Synapse's handling of the backfill endpoint is described here: https://github.com/matrix-org/synapse/blob/207b1737ee0acd226359d59ce3b7f7d46111b1c8/synapse/handlers/federation.py#L829-L837 This also includes a mention that https://github.com/matrix-org/matrix-doc/pull/1594 should render the `auth_events` limitation unnecessary. No changes are required to the the "checks on receipt of a PDU" section of the server-server spec as it starts with "must be a valid event", to which an event is invalid if it contains too many prev or auth events. --- api/server-server/backfill.yaml | 8 ++++++++ api/server-server/definitions/pdu_v3.yaml | 6 ++++++ api/server-server/definitions/pdu_v4.yaml | 6 ++++++ api/server-server/definitions/unsigned_pdu_base.yaml | 6 ++++++ 4 files changed, 26 insertions(+) diff --git a/api/server-server/backfill.yaml b/api/server-server/backfill.yaml index 2ed6298c..d53de6c0 100644 --- a/api/server-server/backfill.yaml +++ b/api/server-server/backfill.yaml @@ -63,6 +63,14 @@ paths: description: |- A transaction containing the PDUs that preceded the given event(s), including the given event(s), up to the given limit. + + .. Note:: + Though the PDU definitions require that ``prev_events`` and ``auth_events`` be limited + in number, the response of backfill MUST NOT be validated on these specific restrictions. + + Due to historical reasons, it is possible that events which were previously accepted + would now be rejected by these limitations. The events should be rejected per usual by + the ``/send``, ``/get_missing_events``, and remaining endpoints. schema: $ref: "definitions/unlimited_pdu_transaction.yaml" "/get_missing_events/{roomId}": diff --git a/api/server-server/definitions/pdu_v3.yaml b/api/server-server/definitions/pdu_v3.yaml index 38105098..3e69d941 100644 --- a/api/server-server/definitions/pdu_v3.yaml +++ b/api/server-server/definitions/pdu_v3.yaml @@ -32,6 +32,10 @@ allOf: description: |- Event IDs for the authorization events that would allow this event to be in the room. + + Must contain less than or equal to 10 events. Note that if the relevant + auth event selection rules are used, this restriction should never be + encountered. example: ["$base64EncodedHash", "$AnotherEvent"] prev_events: type: array @@ -41,6 +45,8 @@ allOf: description: |- Event IDs for the most recent events in the room that the homeserver was aware of when it made this event. + + Must contain less than or equal to 20 events. example: ["$base64EncodedHash", "$AnotherEvent"] hashes: type: object diff --git a/api/server-server/definitions/pdu_v4.yaml b/api/server-server/definitions/pdu_v4.yaml index a045e657..d22956c6 100644 --- a/api/server-server/definitions/pdu_v4.yaml +++ b/api/server-server/definitions/pdu_v4.yaml @@ -32,6 +32,10 @@ allOf: description: |- Event IDs for the authorization events that would allow this event to be in the room. + + Must contain less than or equal to 10 events. Note that if the relevant + auth event selection rules are used, this restriction should never be + encountered. example: ["$URLsafe-base64EncodedHash", "$Another_Event"] prev_events: type: array @@ -41,6 +45,8 @@ allOf: description: |- Event IDs for the most recent events in the room that the homeserver was aware of when it made this event. + + Must contain less than or equal to 20 events. example: ["$URLsafe-base64EncodedHash", "$Another_Event"] required: - auth_events diff --git a/api/server-server/definitions/unsigned_pdu_base.yaml b/api/server-server/definitions/unsigned_pdu_base.yaml index 283e4fed..f1485b55 100644 --- a/api/server-server/definitions/unsigned_pdu_base.yaml +++ b/api/server-server/definitions/unsigned_pdu_base.yaml @@ -53,6 +53,8 @@ properties: description: |- Event IDs and reference hashes for the most recent events in the room that the homeserver was aware of when it made this event. + + Must contain less than or equal to 20 events. items: type: array maxItems: 2 @@ -84,6 +86,10 @@ properties: description: |- Event IDs and reference hashes for the authorization events that would allow this event to be in the room. + + Must contain less than or equal to 10 events. Note that if the relevant + auth event selection rules are used, this restriction should never be + encountered. items: type: array maxItems: 2 From 9599c3bc99bd1e7a2914d868f7349da4e9707b6f Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 12 May 2020 19:03:53 -0600 Subject: [PATCH 78/79] changelog --- changelogs/server_server/newsfragments/2538.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/server_server/newsfragments/2538.clarification diff --git a/changelogs/server_server/newsfragments/2538.clarification b/changelogs/server_server/newsfragments/2538.clarification new file mode 100644 index 00000000..be6f769e --- /dev/null +++ b/changelogs/server_server/newsfragments/2538.clarification @@ -0,0 +1 @@ +Clarify the limits of ``prev_event``s and ``auth_events`` for PDUs. From 05228bf40be9eb89b225924f74b497119d1dac62 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 12 May 2020 19:13:16 -0600 Subject: [PATCH 79/79] ``s -> s`` --- changelogs/server_server/newsfragments/2538.clarification | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/changelogs/server_server/newsfragments/2538.clarification b/changelogs/server_server/newsfragments/2538.clarification index be6f769e..4b709a8d 100644 --- a/changelogs/server_server/newsfragments/2538.clarification +++ b/changelogs/server_server/newsfragments/2538.clarification @@ -1 +1 @@ -Clarify the limits of ``prev_event``s and ``auth_events`` for PDUs. +Clarify the limits of ``prev_events`` and ``auth_events`` for PDUs.