-
Notifications
You must be signed in to change notification settings - Fork 377
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
MSC1954: Proposal to remove prev_content from the essential keys list #1954
MSC1954: Proposal to remove prev_content from the essential keys list #1954
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like the right approach to me
## Security considerations | ||
|
||
I am unaware of any security issues related to this proposal, but can certainly | ||
see issues with a precedent that the federation deviates from the spec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, keeping prev_content
as the current text of the spec says carries a security implication: if somebody stuffed, e.g., illegal or abusive data into a state event and then overwritten the same state event once, those data would be carefully preserved and disseminated via prev_content
even after redaction (if implemented as-per-spec). Therefore prev_content
is not just inessential, it's harmful if kept by redaction. Not sure if we should add it specifically here but it's probably worth stating at least.
in an attempt to help @neilisfragile get this through: @mscbot fcp merge |
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people: No concerns currently listed. Once a majority of reviewers approve (and none object), 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 info about what commands tagged team members can give me. |
Seems entirely reasonable |
the server(s). Client authors will have to update their code to drop | ||
```prev_content``` - however, given that prev_content should not be used in | ||
important calculations and/or visualisations, this ought to be relatively | ||
uninvaisive change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uninvaisive change. | |
uninvasive change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
noninvasive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approve the contents, modulo the typo
## Potential issues | ||
|
||
It is theoretically possible that a closed federation could exist whose servers | ||
do follow the spec as is. This MSC would render those servers uncompliant with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do follow the spec as is. This MSC would render those servers uncompliant with | |
do follow the spec as is. This MSC would render those servers incompliant with |
Makes sense to me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
This doesn't need an implementation because the implementation is already correct. The spec is wrong in this scenario. Flagging it as spec-pr-missing and spec-bug due to the nature of the problem. |
Spec PR: #2016 |
merged 🎉 |
Rendered