helix recent merged a workspace trust model, which given the security impacts of blindly trusting any workspace, is a great enhancement.
The current trust model is showing a pop up whenever a new workspace is opened for which the trust is unclear. This will work well for users who or mostly working on a fixed set of paths or who don't mind pop ups.
Requirements
tl;dr
- configuration option to deny trust by default, instead of prompting
- option for simple pattern matching, instead of log list of paths
- allowing to share trust configuration between machines (via external tools)
- no popup when no unsafe feature is used anyway
- LSP configuration should include an
is_safe_for_untrusted_input: bool
1. configuration option to deny trust by default, instead of prompting
There are however users who are absolutely allergic to pop ups (like me), as they force users to spent their attention on the pop up rather than on the document a user wanted to open. The only option to completely prevents the pop ups being slapped in your face shown on startup is to blindly trust all workspaces. However, users allergic to pop ups may still care about security.
2. option for simple pattern matching, instead of log list of paths
Another point of friction is that the current approach to decide one path of a time can result in a lot of churn when paths are not constant. E.g. users of git worktrees usually have a folder structure like:
~/repos
└── helix
├── branch_a
├── branch_b
├── branch_c
├── ext-branch_d
└── ext-branch_e
or
~/repos
└── helix
├── origin
│ ├── branch_a
│ ├── branch_b
│ └── branch_c
├── pr_user_1
│ └── branch_d
└── pr_user_2
└── branch_e
Since branches get created, merged, dropped, the last segment in the paths will be in constant flux, resulting in frequent interactions with the trust system. However, the trust for both examples could be fully described with a bit more flexible format. E.g. in the first case, "trust ~/repos/helix/* except for ~/repos/helix/ext-*" and in the latter case with "trust ~/repos/helix/origin/*". Note that while globbing is used here in the example, other pattern matching approaches (e.g. regex based) would also solve the requirement.
3. allowing to share trust configuration between machines (via external tools)
First brought up here be @senekor, some users may work on multiple machines but will use the same folder layout on each of them. Being able to share the configuration file (with an external tool) allows those users to extend the trust configuration on one machine and profit from that on all other machines.
4. no popup when no unsafe feature is used anyway
helix should check first if trusting the workspace would change behavior. If there is no benefit in trusting the workspace, it could be just left untrusted without prompting the user.
5. LSP configuration should include an is_safe_for_untrusted_input: bool
Not every feature disabled on an untrusted workspace is actually unsafe for untrusted input. Specifically, some LSPs are safe to be run on untrusted inputs, e.g. typos-lsp. The LSP configuration could be extended with an, say, is_safe_for_untrusted_input: bool that defaults to false. For each LSP that actually is safe to be run on untrusted input, this later can then be enabled.
helix recent merged a workspace trust model, which given the security impacts of blindly trusting any workspace, is a great enhancement.
The current trust model is showing a pop up whenever a new workspace is opened for which the trust is unclear. This will work well for users who or mostly working on a fixed set of paths or who don't mind pop ups.
Requirements
tl;dr
is_safe_for_untrusted_input: bool1. configuration option to deny trust by default, instead of prompting
There are however users who are absolutely allergic to pop ups (like me), as they force users to spent their attention on the pop up rather than on the document a user wanted to open. The only option to completely prevents the pop ups being
slapped in your faceshown on startup is to blindly trust all workspaces. However, users allergic to pop ups may still care about security.2. option for simple pattern matching, instead of log list of paths
Another point of friction is that the current approach to decide one path of a time can result in a lot of churn when paths are not constant. E.g. users of git worktrees usually have a folder structure like:
or
Since branches get created, merged, dropped, the last segment in the paths will be in constant flux, resulting in frequent interactions with the trust system. However, the trust for both examples could be fully described with a bit more flexible format. E.g. in the first case, "trust
~/repos/helix/*except for~/repos/helix/ext-*" and in the latter case with "trust~/repos/helix/origin/*". Note that while globbing is used here in the example, other pattern matching approaches (e.g. regex based) would also solve the requirement.3. allowing to share trust configuration between machines (via external tools)
First brought up here be @senekor, some users may work on multiple machines but will use the same folder layout on each of them. Being able to share the configuration file (with an external tool) allows those users to extend the trust configuration on one machine and profit from that on all other machines.
4. no popup when no unsafe feature is used anyway
helix should check first if trusting the workspace would change behavior. If there is no benefit in trusting the workspace, it could be just left untrusted without prompting the user.
5. LSP configuration should include an
is_safe_for_untrusted_input: boolNot every feature disabled on an untrusted workspace is actually unsafe for untrusted input. Specifically, some LSPs are safe to be run on untrusted inputs, e.g. typos-lsp. The LSP configuration could be extended with an, say,
is_safe_for_untrusted_input: boolthat defaults tofalse. For each LSP that actually is safe to be run on untrusted input, this later can then be enabled.