sammccall added a comment. In D92155#2453597 <https://reviews.llvm.org/D92155#2453597>, @psionic12 wrote:
> In D92155#2450474 <https://reviews.llvm.org/D92155#2450474>, @nridge wrote: > >> 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? Hmm, maybe... I thought `getConfiguration('clangd')` with no scope specified was supposed to be global (i.e. not a workspace-specific setting). There's a scope you can pass in, and we're not providing one. Nevertheless testing it locally these flags do seem to be used. We should fix this, I think `workspace.getConfiguration('clangd').inspect('arguments')` and then applying the components manually makes it possible. This is a horrible breaking change, though :-( Alternatives would be treating clangd args as untrusted too, conceding that opening a file in vscode can own the user, some list of safe flags... > 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. I can't agree with this, even if other problems exist, it's not OK to introduce a big problem with a broad scope, when we have alternatives. 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
