Skip warning message for clanngd.path/clangd.arguments when user trust workspace.

[simon8233]

I understand this feature is important under open software development.

I use vscode workspace spec to setup remote index server and user local configure path with different codebase/project to speed up internal user usage

Is it possible to skip the warning message when user chooses "Yes, I trust the authors" on VS Code workspace opening?

or

Is it possible to add configure option (to disable it) in clangd configure of user-level VS Code or $HOME/.clangd

I think the first one is better than the second solution due to user already click trust workspace author

It will help internal usage cases I think.

[HighCommander4]

Looked into this a bit. The vscode feature that prompts you to trust a workspace when opening it is called Workspace Trust (user documentation, extension author documentation).

The clangd feature to prompt you when clangd.path or clangd.arguments is overridden (added March 2021) predates Workspace Trust (added in vscode 1.57, released May 2021). It seems to me that Workspace Trust aims to solve a supserset of the problems that the clangd feature solves; in particular, extensions have a way to list configuration options that should only be respected in trusted workspaces.

So, one potential way forward would be to consider clangd's own prompt feature to be obsoleted by Workspace Trust and remove it. (Note, vscode-clangd trunk now requires vscode >= 1.65, so we can safely assume Workspace Trust in forthcoming vscode-clangd versions.)

There are two ways this could work:

• Clangd does not opt into Workspace Trust and therefore is not run at all in Restricted Mode. This is already the case today, but it can be overriden by the user in which case they get the full clangd functionality.
• Clangd opts into Workspace Trust by declaring limited support for Restricted Mode, and using restrictedConfigurations to specify that clangd.path and clangd.arguments should not be respected in Restricted Mode.

The second option seems preferable (not supporting clangd at all in Restricted Mode likely results in some users trusting the workspace when they otherwise wouldn't need to).

Alternatively, if for some reason we feel that Workspace Trust doesn't meet our needs and want to continue to layer our own prompt on top of it, then adding an opt-out in user config seems reasonable. (However, I don't know why we'd want this.)

@sam-mccall, what do you think?

[colas31]

Hi @HighCommander4 ,

I'm following this discussion too.

I'm not sure to understand exactly the two ways relied on Workspace Trust you explained.

To provide you more context why this improvement is needed for us and why the last option (adding an opt-out in user config) is perfect.

In our case, we automotize the setup of VSCode for each developper to gain time and avoid them the misconfigure the project. We developed an internal extension that installs all recommended extension for the project and configure each extension for exemple it sets the clangd.path and clangd.arguments . The default one can not be used, clangd is not in the PATH and depending on the project we have to set a different clangd path or arguments.

But once all the configuration is applied, users still have the prompt displayed by clangd extension and sometime users click on the wrong button (No), that generates lot of misunderstanding and bring us support since clangd is not working.

Thanks for your support :)

[HighCommander4]

But once all the configuration is applied, users still have the prompt displayed by clangd extension and sometime users click on the wrong button (No), that generates lot of misunderstanding and bring us support since clangd is not working.

@colas31 Do your users not also get a prompt like this due to vscode's Workspace Trust feature?

[colas31]

I think they have this prompt too. At least I have it when I start from strach

[HighCommander4]

I think they have this prompt too. At least I have it when I start from strach

Right, so my proposal is "when they see that prompt, the additional clangd-specific prompt is redundant and should not be shown". That seems like that would address your use case without any configuration necessary.

My fallback proposal is "when they see that prompt, the additional clangd-specific prompt is not shown depending on the user configuration", which seems like it also addresses your use case (but requires the extra work of you specifying that user configuration).

[simon8233]

Right, so my proposal is "when they see that prompt, the additional clangd-specific prompt is redundant and should not be shown". That seems like that would address your use case without any configuration necessary.

Yes, I think it's a very good solution for automation generating workspace file spec situations.

Very thanks for your reply and discussion.

[colas31]

I think they have this prompt too. At least I have it when I start from strach

Right, so my proposal is "when they see that prompt, the additional clangd-specific prompt is redundant and should not be shown". That seems like that would address your use case without any configuration necessary.

My fallback proposal is "when they see that prompt, the additional clangd-specific prompt is not shown depending on the user configuration", which seems like it also addresses your use case (but requires the extra work of you specifying that user configuration).

Thanks for the clarification, I correctly understand what are the possibilities.

It's your product, I let you choose which is the best implementation. Probably the first proposal is the best it avoid to add a new configuration/setting in your extension.

If needed I can contribute or help to test it.

Thanks again for your time

[sam-mccall]

The clangd feature to prompt you when clangd.path or clangd.arguments is overridden (added March 2021) predates Workspace Trust (added in vscode 1.57, released May 2021).

Right. It was triggered by an investigation coming from Google's security org: https://bugs.chromium.org/p/llvm/issues/detail?id=5

While thinking about mitigations, we did think about a "trust this directory" model, and rejected it for not being secure enough.

The reasons are:

• "do you trust the directory" doesn't make the implications clear, and leaves users with a difficult security decision. They are very likely to click "OK" to get their features working. It seems more like CYA than effective protection.
• diligent users may even check the config, but the setting is sticky and the config may become malicious in future. "I trust anyone who may ever commit to this repo" may apply in some situations, but it's too much in general.

This is why we didn't just "automatically" back this out once VSCode's trusted workspace launched. The security/usability tradeoff is real though, and it's also confusing to have VSCode provide a standard mechanism and for us not to use it. On balance I think it's probably better to follow VSCode conventions and accept that it's not particularly secure :-(

The second option seems preferable (not supporting clangd at all in Restricted Mode likely results in some users trusting the workspace when they otherwise wouldn't need to).

Agree. The risk here is clangd is not particularly hardened, but on balance if you can't set --query-driver without trust we're probably good.

Alternatively, if for some reason we feel that Workspace Trust doesn't meet our needs and want to continue to layer our own prompt on top of it, then adding an opt-out in user config seems reasonable. (However, I don't know why we'd want this.)

@sam-mccall, what do you think

I think there are good reasons to want this, but switching to workspace trust as you mentioned would win on balance.

[i-ky]

On balance I think it's probably better to follow VSCode conventions and accept that it's not particularly secure :-(

You don't have to accept VS Code unsafe conventions. I think you can raise the issue with VS Code maintainers if you find its conventions/API not safe enough.

[tru]

My attempt: https://github.com/clangd/vscode-clangd/pull/451

[tru]

This was merged so this can be closed.

[HighCommander4]

Thanks for implementing!

[cpsauer]

Another big thanks from me :)