Skip to content

Invalid boolean config values are silently treated as false #2268

Description

@viktorerlingsson

An unrecognised value for any boolean config option is silently parsed as false, with no warning and no error, in both [main] and [sni:] sections:

[main] tls_prefer_server_ciphers = 'yse'     -> false
[main] data_dir_lock             = 'garbage' -> false
[sni]  tls_prefer_server_ciphers = 'enabled' -> false
[sni]  tls_verify_peer           = 'oui'     -> false

Accepted spellings are 1/true/yes/on/y and 0/false/no/off/n, case-insensitive since #2264. Anything else falls through to false in Config#true?.

This is inconsistent with how other types are handled: segment_size = notanumber raises and the whole config is rejected, but a misspelled boolean quietly changes behaviour. It matters most for options that default to on, such as data_dir_lock, and for security-relevant ones like tls_verify_peer and tls_prefer_server_ciphers, where a typo silently weakens the configuration.

Long-standing behaviour, unchanged since #917, so this is not a regression. Filed for the record rather than as something urgent.

Options if it is ever picked up: log a warning naming the key and the accepted values, or raise like the integer options do. Raising is more consistent but would stop a node with a pre-existing typo from booting after an upgrade.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions