danmar
document external file lookup order [skip ci]
The current behavior of the lookup of external files is wildly inconsistent for each type and depends on if you are using the GUI or CLI. This can be mostly observed in test/cli/lookup_test.py (CLI) and https://trac.cppcheck.net/ticket/12752 (GUI).
This is a PR to determine the intended(!) order of the lookup of external files with goal of having a defined and shared implementation. The current change of the manual contains what I consider the most sensible order. Obviously open to any discussion/feedback on this.
I also considered making some of these lookups configurable to avoid some potentially unwanted behavior: https://trac.cppcheck.net/ticket/12810 https://trac.cppcheck.net/ticket/13505
There's also other related tickets: https://trac.cppcheck.net/ticket/10774 https://trac.cppcheck.net/ticket/13880
I did not include a list of the known issues as those are mostly evident by above references and should not affect the discussion and are simply the steps to ensure we arrive at the intended behavior.
CC @danmar @ludviggunne @andresailer @ledocc @nlebedenco @c72578
A case against supporting CWD in the lookup (from https://github.com/danmar/cppcheck/pull/7639#discussion_r2192049596):
"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."
A case against supporting CWD in the lookup (from https://github.com/danmar/cppcheck/pull/7639#discussion_r2192049596):
Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.
"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."
I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..
Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.
It looks relative to the project file. Looking relative to the CWD is a different lookup. That should be evident in the expected output of test/cli/lookup_test.py
I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..
It will probably be installed in some common location. If files are distributed with it they would be placed relative to that so it will use the lookup relative to the executable location.
But you just gave the use case for CWD. If you have a custom script which invokes it you might place addition or overrides next to the script. The question though if CWD should override the project file - I think not, because the more specialized location should always override the more common ones.
But you just gave the use case for CWD. If you have a custom script which invokes it you might place addition or overrides next to the script. The question though if CWD should override the project file - I think not, because the more specialized location should always override the more common ones.
great. that is fine for me. so look in the project file folder first if that exist. and then look in CWD folder..
great. that is fine for me. so look in the project file folder first if that exist. and then look in CWD folder..
I am still a bit torn of supporting CWD. Because if you invoke the tool you might do so from a random path since the executable is in PATH. So that might pick up a stray file. Still there is your use-case.
clang-tidy is also picking up config files but that is starting from the source location and then walks up the tree. That is something we currently do not do. That would actually be similar to the project file behavior.
But clang-tidy also lets you specify config file locations. So we could add an option to inject a path in the lookup (which would be super easy when all the lookups have been converted to walking a list of paths).
I am still a bit torn of supporting CWD. Because if you invoke the tool you might do so from a random path since the executable is in
PATH. So that might pick up a stray file. Still there is your use-case.
Picking up random files from CWD always reminds me of DLL injection vulnerabilities so maybe that behavior should be configurable. Since we execute Python code I wonder if we restrict that execution out-of-the-box (e.g. restrict process permissions, sandboxing, ...) so the code we run cannot do any obviously malicious things (an option could disable that).
I filed https://trac.cppcheck.net/ticket/14237 about that.
Well an option could be added to specify this path. However my feeling is that there are many users that have been putting custom platform files or configuration files in the project folder for years. Several customers do this. So my suggestion is that the default value is "." and then it can be overridden.
Imho, I feel that this is like when I write "cat foo.txt" in a shell script and cat will look for "foo.txt" in cwd. We can document the lookup instead of adding an option.
Manual can be improved:
- The manual tells the user that he can create a custom platform file, my intention was that it would be put in the project folder however that is not explicitly written.
- For addons the manual says "Cppcheck search for addons in the local folder first and then in the installation folder."
- The manual says that a custom .cfg file can be created but it's not explicit about the lookup order. My intention was that it would be possible to put custom .cfg files in the project folder.
Since we execute Python code I wonder if we restrict that execution out-of-the-box (e.g. restrict process permissions, sandboxing, ...) so the code we run cannot do any obviously malicious things (an option could disable that).
unfortunately we don't. And chat gpt said that there is no such python option :-(
I guess it's impossible for the python binary to control what all libraries do :-(
Sandbox solution: Cppcheck can be executed for example in a docker container. We can document how it's done. I would not suggest that we implement docker support in cppcheck.
For the python scripts I feel sympathy for your security concerns. I do want to allow that custom scripts are written that are put in the project folder. I do not feel sure that an extra option that specify the project path would help we can still get this exact security problem. I.e. if the shell script that runs cppcheck says something like --project-path=$CWD. Your suggestion to restrict python somehow should be investigated.
How about a simple python parser that parse the script and checks:
- only allow that specific libraries are imported. I.e. only allow cppcheckdata, cppcheck and re.
- do not allow that 'open' is used