[PATCH] D92155: Load plugins when creating a CompilerInvocation.
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Dec 15 00:23:24 PST 2020
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
More information about the cfe-commits
mailing list