psionic12 added a comment. In D92155#2450474 <https://reviews.llvm.org/D92155#2450474>, @nridge wrote:
> In D92155#2419549 <https://reviews.llvm.org/D92155#2419549>, @sammccall wrote: > >> In D92155#2419346 <https://reviews.llvm.org/D92155#2419346>, @psionic12 >> wrote: >> >>> Or, could you help to point out what's the difference between passing a >>> plugin path through *clangd* startup command line and through clang flags? >> >> Sure. TL;DR is: clangd flags are configured by the user, user can be fully >> responsible for security/stability. >> clang flags are configured by the project. If they're bad, we can e.g. give >> bad diagnostics, but can't crash or compromise security. >> >> More detail: >> >> In the simplest possible case, clangd is configured as follows: >> >> 1. user downloads clangd binary >> 2. user installs an LSP plugin for their editor, and configures the plugin >> to use /usr/bin/clangd for C++ files. clangd starts when the editor does >> 3. the build system for $PROJECT generates $PROJECT/compile_commands.json >> 4. when the user opens $PROJECT/src/foo.cpp in the editor, it notifies >> clangd. clangd searches for $PROJECT/compile_commands.json, finds the clang >> arguments, and uses them to parse foo.cpp >> >> *clangd* command-line flags would be added explicitly by the user at step 2. >> We can reasonably ask the user to be aware/responsible for >> security/stability implications of doing this, including with their >> particular clangd version. We can also ask them to run `clangd --check` >> without the plugin flag to test whether the plugin is causing a stability >> problem. >> >> *clang* command-line flags are added implicitly in step 3. Or they could >> simply be checked into the repository - nothing ensures they were generated >> locally by the build system. The point is in typical usage they are not >> controlled by the user directly, and from a security perspective are not >> trusted (as safely opening files from untrusted repos is a reasonable >> expectation). So if we're loading plugins based on instructions in clang >> command-line flags, clangd bears most of the responsibility for making sure >> that's safe and correct (and I don't see a way to do that). > > Something just occurred to me: can't clangd arguments also be controlled by > the untrusted repository by having a `.vscode/settings.json` file with > specificed `"clangd.arguments"` checked in? Yeah, there are too many ways to pass an argument without user's awareness, all the safety protections we talked about aren't help much, and I think this is not the clangd's problem, it exists in clang as well. So I think loading plugin codes guarded with CLANG_PLUGIN_SUPPORT on is enough, no more complicity protections should added. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92155/new/ https://reviews.llvm.org/D92155 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
