WEST_CONFIG_* accept relative paths

[marc-hb]

I accidentally found this while testing #867 but it predates #867

I think this is a serious issue because:

• west config and (build) output can depend on the current directory. I think they never should because that can lead to hours or even days of troubleshooting. For instance imagine compiler flags that "silently" come and go.
• More severely, I think this is a significant attack surface very similar to what @mbolivar described in [draft] Support dropin config files (within .d directories) #849 (comment)

So, I think relative paths in WEST_CONFIG_* should be rejected or anchored, see below. However, this is technically a backwards-incompatible change. I mean some users could have actually relied on that to "dynamically" change their configuration. They shouldn't have, but they might have...

[marc-hb]

One middle ground would be to anchor all relative paths to the west topdir. This would be consistent with other west features while preserving some past configurations.

I mean some users could have actually relied on that to "dynamically" change their configuration.

It would still break that - by design.

[pdgendt]

I accidentally found this while testing #867 but it predates #867

I think this is a serious issue because:

• west config and (build) output can depend on the current directory. I think they never should because that can lead to hours or even days of troubleshooting. For instance imagine compiler flags that "silently" come and go.
• More severely, I think this is a significant attack surface very similar to what @mbolivar described in Support dropin config files (within .d directories) #849 (comment)

I agree we need to make the behavior clear and consistent, but I doubt this currently has a big impact. Nevertheless an issue we should tackle, good find.

So, I think relative paths in WEST_CONFIG_* should be rejected or anchored, see below. However, this is technically a backwards-incompatible change. I mean some users could have actually relied on that to "dynamically" change their configuration. They shouldn't have, but they might have...

We're not breaking anything if it was never intentional nor documented IMO.

One middle ground would be to anchor all relative paths to the west topdir. This would be consistent with other west features while preserving some past configurations.

Sounds good.

[thorsten-klein]

anchor all relative paths to the west topdir

I don't like this idea. People might start to set the env variable in their .bashrc. Then sometimes the relative path is considered and sometimes not, depending if the config file is present in their local workspace or not. Exactly this can lead to hours or even days of troubleshooting.

So I really prefer to always enforce absolute configs paths.

[marc-hb]

We're not breaking anything if it was never intentional nor documented IMO.

It's the well known "Hyrum's law".

I don't like this idea. People might start to set the env variable in their .bashrc. Then sometimes the relative path is considered and sometimes not, depending if the config file is present in their local workspace or not. Exactly this can lead to hours or even days of troubleshooting.

You misunderstood me. I meant: we can decide to make relative paths always relative to the west topdir and convert them to absolute paths early (whether the file exists or not). Not "sometimes" relative to something but always relative to the same thing = "anchored". For obvious reasons, the WEST_CONFIG_* variables have always accepted optional files that may exist or not, your #867 does not change that and that is a good thing. We only want the location not to move around.

Like this you can have someone who always wants to have an (optional) west_projectA/my_west_config, west_projectB/my_west_config, etc. I believe this works already right now! As long as you keep current directory equal to west topdir, which is not a stretch. We can easily preserve that. It becomes even more useful after your #867

[mbolivar]

I'd rather not be assigned to this issue, but I think this isn't as big of a problem because if you can control the user's environment, the user has bigger problems (e.g. if you can write to PATH, it's pretty much game over). So I don't see this as a real issue but I might be missing something.