[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