Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3667: Enforce integer power levels #3667

Merged
merged 5 commits into from
Mar 27, 2022
Merged

MSC3667: Enforce integer power levels #3667

merged 5 commits into from
Mar 27, 2022

Conversation

neilalexander
Copy link
Contributor

@neilalexander neilalexander commented Jan 21, 2022

@neilalexander neilalexander changed the title MSCXXXX: Enforce integer power levels MSC3667: Enforce integer power levels Jan 21, 2022
@turt2live turt2live added needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal proposal-in-review requires-room-version An idea which will require a bump in room version unassigned-room-version Remove this label when things get versioned. s2s Server-to-Server API (federation) labels Jan 21, 2022
@neilalexander neilalexander mentioned this pull request Jan 24, 2022
2 tasks
@turt2live turt2live self-requested a review January 24, 2022 14:47
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally seems fine to me - just a bit of clarity before I think this is ready for FCP.

Comment on lines 22 to 24
In a future room version, we should enforce the letter of the spec and only allow power levels
as integers and reject events which try to define them as any other type. This removes all of the
associated headaches with string parsing.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For clarity, which system are we hoping to enforce this within? If it's the auth rules then they might be complicated to represent, but if it's just evaluation-time parsing (ie: non-int is default power level) then that might be a bit easier to write.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to modify the auth rules themselves here. I think an acceptable outcome is that parsing the power level content at the beginning of event auth altogether fails, therefore auth fails with it. This is what the Dendrite implementation does currently. We don't attempt to fall back to a default level, although if anyone has feelings on whether that approach would be better, I'd welcome opinions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failing event auth sounds ideal - can we get words to that effect in the MSC? 😇

@@ -0,0 +1,42 @@
# MSC3667: Enforce integer power levels
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just to pre-empt some potential discussion: other event types, like join rules, aren't really subject to the same nuances that integer-based power levels are. As a power event itself in state res v2, the power levels are critical for determining whether or not a user can do something - the same issue can theoretically arise from incorrect membership or join rule, however the handling of those two events is targeted at the specific enum values whereas power levels are a range.

@turt2live turt2live removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jan 24, 2022
Comment on lines 17 to 18
All of this behaviour is exceptionally difficult for non-Python implementations to reproduce
accurately, so we should not try to do so.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not specifically, i've drawn an algorithm to come close; (original comment)

  1. trim all whitespace
  2. remove leading +
  3. if leading character is -, remove and remember
  4. remove leading zeroes (except the last one, if remaining string is all-zeroes)
  5. interpret string as an integer
  6. if - was encountered, negate the integer

I'm plenty sure this is how python does it, and i think at least a mention/help for the spec on how to start to parse the old values would help a ton.

Comment on lines +3 to +4
The spec defines power levels in `m.room.power_levels` events as integers, but due to legacy
behaviour in Synapse, string power levels are also accepted and parsed. The string parsing itself
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This first sentence is a little confusing. String power levels are not accepted by the spec - but in practice are often accepted by homeserver implementations as not doing so would break existing rooms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spec PR #3688 will formally allow today's behaviour into the spec for all room versions up to and including version 9, since this issue was still not yet fixed in Synapse. That will allow us and future implementations to preserve compatibility with existing rooms.

This MSC, on the other hand, will fix the problem in future room versions (hopefully from room version 10).

Comment on lines +28 to +31
We can't avoid the string parsing behaviour altogether because we need to continue to do so for
existing room versions so that we do not break existing rooms. However, there are already documented
cases of this causing problems across implementations. For example, Synapse will accept `" +2 "` as
a power level but Dendrite will outright fail to parse it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have a line here explicitly stating that: as a result, homeserver implementations may need to update their existing room version implementations to remain compatible with the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is my hope that the wording in #3688 will be sufficient to cover what implementations should do today and then this MSC can focus on what we do to plug the hole going forward.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(directionally, I think it's best to work on this MSC and that spec PR almost concurrently: the MSC can make reference to what the spec intended to say, as we know we'd accept a clarification about how stringy power levels work, and the spec PR can either continue working on inclusion or wait for this MSC to land and be assigned a room version)

@turt2live
Copy link
Member

This seems possible to implement in at least two implementations (Synapse and Dendrite), and overall this MSC seems ready to go.

I'm not an expert on where the validation should be applied, but hopefully one of these folks is:

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Feb 10, 2022

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added disposition-merge proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. and removed proposal-in-review labels Feb 10, 2022
@mscbot
Copy link
Collaborator

mscbot commented Mar 27, 2022

The final comment period, with a disposition to merge, as per the review above, is now complete.

@mscbot mscbot added finished-final-comment-period and removed disposition-merge final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. labels Mar 27, 2022
@turt2live turt2live merged commit 03f8ce9 into main Mar 27, 2022
@turt2live turt2live added spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec and removed finished-final-comment-period labels Mar 27, 2022
@turt2live turt2live self-assigned this Mar 27, 2022
@turt2live
Copy link
Member

This MSC is assigned to v10: #3604

@turt2live
Copy link
Member

Spec PR: matrix-org/matrix-spec#1099

@turt2live turt2live added spec-pr-in-review A proposal which has been PR'd against the spec and is in review and removed spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec labels May 30, 2022
@turt2live turt2live added merged A proposal whose PR has merged into the spec! and removed spec-pr-in-review A proposal which has been PR'd against the spec and is in review labels Jun 8, 2022
@turt2live
Copy link
Member

Merged 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:core MSC which is critical to the protocol's success merged A proposal whose PR has merged into the spec! proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version s2s Server-to-Server API (federation)
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.