Fix handling of "off" in encryption_enabled_by_default_for_room_type#7822
Conversation
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.
clokep
left a comment
clokep
left a comment
There was a problem hiding this comment.
Makes sense. Did you check if we use the literal string "off" for any other settings?
|
Yes, that's what I meant by
|
I guess it helps if I read the whole description. 🤦 Thanks! |
* commit '504c8f348': Fix handling of "off" in encryption_enabled_by_default_for_room_type (#7822) Update grafana dashboard
| # 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.
5 participants
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.