document external file lookup order [skip ci] #7613
Conversation
|
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 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: There's also other related tickets: 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 #7639 (comment)): "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." |
Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder. |
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 looks relative to the project file. Looking relative to the CWD is a different lookup. That should be evident in the expected output of
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. |
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 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). |
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:
|
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 How about a simple python parser that parse the script and checks:
|
2 participants
No description provided.