This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Fix handling of "off" in encryption_enabled_by_default_for_room_type #7822
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes #7821, introduced in #7639 Turns out PyYAML translates `off` into a `False` boolean if it's unquoted (see https://stackoverflow.com/questions/36463531/pyyaml-automatically-converting-certain-keys-to-boolean-values), which seems to be a liberal interpretation of this bit of the YAML spec: https://yaml.org/spec/1.1/current.html#id864510 An alternative fix would be to implement the solution mentioned in the SO post linked above, but I'm aware it might break existing setups (which might use these values in the configuration file) so it's probably better just to add an extra check for this one. We should be aware that this is a thing for the next times we do that though. I didn't find any other occurrence of this bug elsewhere in the codebase.
auscompgeek
reviewed
Jul 11, 2020
clokep
approved these changes
Jul 13, 2020
|
Yes, that's what I meant by
|
I guess it helps if I read the whole description. 🤦 Thanks! |
babolivier
pushed a commit
that referenced
this pull request
Sep 1, 2021
* commit '504c8f348': Fix handling of "off" in encryption_enabled_by_default_for_room_type (#7822) Update grafana dashboard
DMRobertson
reviewed
May 16, 2022
Comment on lines
+57
to
+58
| # PyYAML translates "off" into False if it's unquoted, so we also need to | ||
| # check for encryption_for_room_type being False. |
There was a problem hiding this comment.
This is not a PyYAML quirk; this is part of YAML itself; c.f. the famous Norway Problem.
There was a problem hiding this comment.
To be extra pedantic, it's part of YAML 1.1 and not present in YAML 1.2.2, or at least not mentioned in the spec: https://yaml.org/spec/1.2.2/#1032-tag-resolution
PyYAML implements YAML 1.1 I believe.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #7821, introduced in #7639
Turns out PyYAML translates
offinto aFalseboolean if it'sunquoted (see https://stackoverflow.com/questions/36463531/pyyaml-automatically-converting-certain-keys-to-boolean-values),
which seems to be a liberal interpretation of this bit of the YAML spec: https://yaml.org/spec/1.1/current.html#id864510
An alternative fix would be to implement the solution mentioned in the
SO post linked above, but I'm aware it might break existing setups
(which might use these values in the configuration file) so it's
probably better just to add an extra check for this one. We should be
aware that this is a thing for the next times we do that though.
I didn't find any other occurrence of this bug elsewhere in the
codebase.