draft: impl workspace trust

[usering-around]

Currently it is a proof concept of workspace trust. It adds a configuration option editor.workspace-trust which can be either:

• always - always trust the workspace (current behavior of helix)
• ask - show a trust dialog whenever you open a new workspace (new default)
• manual - same thing as ask but without asking (i.e. the user has to bring up the trust dialog themselves via :trust-dialog, or use the commands :trust-workspace/:untrust-workspace)
• never - never trust workspaces.

When a workspace is untrusted, you can't use LSPs/debuggers/formatters and workspace config.
It's implemented via a global trust database which is backed by a file.

Some things I'd like feedback about:

• How should the trust database be implemented?
  Currently it's implemented in a TOML file in XDG_STATE_HOME with fall back to the data directory on windows. Writes are guarded by a .lock file and are done atomically via fsync and tempfile persistence. There's no guards for reading since the writes are atomic.
  The first read/write to the database result in it being cached in memory. Any updates to the database from outside the process are not reflected on this cache. Any write to the database within the process updates the in memory cache. The in memory cache is implemented with arc_swap.
  Note: if we bump rust to 1.89.0 the dependency on fs2 can be removed in favor of the File::lock API.

Old database

A TOML file in `~/.local/share/trust_db.toml` (and appropriate path on windows) guarded by a `.lock` file on each read & write. When you write to the database, it serializes the entire database and writes it (obviously not ideal). The lock mechanism could be replaced with https://github.com/untitaker/rust-atomicwrites (or with a custom implementation for atomic files via rename) for more reliablity and read performance.

Here's an example of how it looks:

[trust]
"/home/user/.local/share/helix/trust_db.toml" = "Trusted"
"/home/user/some_python_file.py" = "Trusted"
"/home/user/some_workspace" = "Untrusted"
"/home/user/some_other_workspace" = "Trusted"

• How should the trust dialog look? Currently it looks like so:

Uncolored (old)

Parent folder picker:

Old trust dialog

For workspaces: For singular files:

Perhaps there should be a new widget for dialogs? Currently using the select component from https://github.com/the-mikedavis/helix/tree/workspace-trust

• Should we auto start LSPs and auto reload config when the user trusts/untrusts the workspace, or should we let them do :lsp-restart and :config-reload manually?

• Perhaps the never option should be removed and users should just use the manual option if they want this behavior?

and of course any other feedback is also welcome.

Todo list for what needs to be done before this is ready for review:

• Do not panic when serialization/deserialization of the database fail
• Investigate why job::dispatch_blocking in the DocumentDidOpen hook hangs when opening a singular document with hx (currently it uses tokio::spawn with job::dispatch to work around this)
• Make the lsp server turn on when you trust for the first time & same thing with but with reloading config
• Add documentation (both for the code and for the workspace-trust option)
• Use OnceLock<ArcSwap> instead of ArcSwapOption in SimpleDb
• Add logging?
• check the reliablity of testing that a document is in a workspace withPath::starts_with (in helix-view/src/editor.rs)
• auto trust newly created files the user is writing? (if they're not already in a workspace of course)
• Wait for the Select component or something equivalent to be added to master and use it instead of the current Select component

[the-mikedavis]

I was working on this feature as well but never got the branch over the finish line https://github.com/the-mikedavis/helix/tree/workspace-trust. We need a new UI component for selecting whether or not you want to trust. The picker is not the right tool. See the Select component in that branch. I may just work on landing that change in master first since we can use it for LSP window/showMessageRequest independently of this feature

[usering-around]

We need a new UI component for selecting whether or not you want to trust. The picker is not the right tool. See the Select component in that branch.

It does seem much better. I'll try to integrate it.

I may just work on landing that change in master first since we can use it for LSP window/showMessageRequest independently of this feature

Yes that would be nice if you could. For now I'll add it temporarily and remove it when/if it gets merged into master. If I can help with it in any way let me know.

[usering-around]

Edited the original pull request with new screenshots. The select component looks much better. Only problem is the implementation currently ignores the styling of the elements.
Also, it would be nice if the title was a Spans so we could highlight different parts in the title.

[kumawatdarshan]

I think there should be something to disallow config overrides.
So that malicious code cannot be executed as disguised as services(through .helix/ config override).

[usering-around]

I think there should be something to disallow config overrides. So that malicious code cannot be executed as disguised as services(through .helix/ config override).

The implementation already ignores workspace config if the workspace is untrusted.

[usering-around]

^^
I've added an in memory-cache to the database, so it doesn't need to lock and deserialize the database on each open document. It also now writes to the database atomically, so there shouldn't be any corruption issues.

[usering-around]

added a small todo list