west config corner cases when setting option foo.bar=baz

[mbolivar]

This command:

$ west config foo.bar=baz qux

should, I think, either error out, or set an option named foo.bar=baz to qux.

Instead, it does some mix of the two, because afterwards, running:

$ west config foo.bar=baz

results in west exiting 1 with the option unset , but

$ west config -l | grep foo
foo.bar=baz = qux

something is wrong here, likely related to how configparser deals with = signs

[d3zd3z]

Perhaps consider just forbidding equal signs in the names of configs? Config files are stored in a init-style format, and although have spaces, I suspect don't parse. It doesn't seem the library is expecting these names, and may very well have other characters that aren't workable.

yaml will allow almost anything, if quoted is only going to include alphanumeric, digits, '-', '_',. Dot is allowed but it gets weirdly ambiguous if we are parsing dots. Most punctuation is not allowed, without quoting.

[d3zd3z]

Oh, and yaml will do really weird things if the key can be interpreted as a boolean. It works fine, but the key in the dict is actually the boolean, not a string. Likewise the same will happen with valid numbers.

[marc-hb]

likely related to how configparser deals with = signs

Yes: first '=' sign wins. configparser happily accepts equal signs in keys, writes them to the .ini file without quoting or escaping, and finally interprets the first = sign it finds on the line. I verified this with a debugger.

Simplest demo:

west config --global sect.one=two   three
west config -l
                  => sect.one=two = three
grep -B1 two ~/.westconfig
                  =>      [sect]
                  =>      one=two = three
west config sect.one
                  =>          two = three

configparser writes the second equal sign but reads back the first one.

It's confusing because the way configparser write the .ini file makes you think it cares about spaces. But not really.

Perhaps consider just forbidding equal signs in the names of configs?

Yes; with a pointer to the corresponding configparser bug.

yaml will allow almost anything

Does configparser rely on YAML?

[marc-hb]

https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour states:

delimiters, default value: ('=', ':')

Delimiters are substrings that delimit keys from values within a section. The first occurrence of a delimiting substring on a line is considered a delimiter. This means values (but not keys) can contain the delimiters.

... but configparser does not check whether a key contains a delimiter on input and just writes it as is in the file. I verified this without west. Same bug with :.

[marc-hb]

configparser bug filed with reproduction:

• ConfigParser accepts delimiters in key name which corrupts .ini file python/cpython#128843

[marc-hb]

Someone just linked that bug to other, similar lacks of input validation.

configparser: garbage in => different garbage out.

Apparently you can even fool configparser to create new sections. That sounds very insecure.