Server - Support custom vocabularies

[jdesrosiers]

Is there a way to allow people configure support for custom dialects? There would need to be a way to load a dialect dynamically based on a configuration value. Maybe this can be done via a dynamic import? Can it be done in a reasonably secure way?

[Adityakumar37]

Hi @jdesrosiers, I was going through the codebase trying to understand what it would take to support this and wanted to check if I'm on the right track before diving in.

So from what I can tell, LanguageServerSettings in configuration.js only has defaultDialect and schemaFilePatterns right now. And in build-server.js the dialects are all statically imported, so there's no way to load custom ones dynamically at the moment.

I also noticed that if you put a custom dialect meta-schema in the workspace it does get picked up via registerSchema in schemas.js — but that only works if the dialect is purely declarative. If someone needs addKeyword or defineVocabulary they're stuck because there's no way to load executable JS.

One more thing — validate-vocabulary.test.ts exists but I couldn't find a corresponding validate-vocabulary.js implementation anywhere. Is that intentional or is that part of what this issue is about?

My rough idea was to add something like a customVocabularies field to LanguageServerSettings that points to a local JS module, then dynamically import it on init or when config changes. Since DiagnosticsFeature already uses a pluggable provider pattern it seems like a vocabulary provider could fit in there cleanly too.

Am I understanding this correctly?

[jdesrosiers]

I also noticed that if you put a custom dialect meta-schema in the workspace it does get picked up via registerSchema in schemas.js — but that only works if the dialect is purely declarative. If someone needs addKeyword or defineVocabulary they're stuck because there's no way to load executable JS.

Yep, that sounds like the right understanding of the problem.

My rough idea was to add something like a customVocabularies field to LanguageServerSettings that points to a local JS module, then dynamically import it on init or when config changes.

That won't work. JSON Schemas can be used in any language, so we need a solution that works for any language. A Python project shouldn't be expected to have JavaScript in their codebase. Even in a JavaScript project, I don't think it will work. Not nicely anyway. The project and the language server aren't running in the same environment and the language server environment isn't available in local module. So, you can probably run a local script within the language server, but you can't check it for errors with linters and type checking or include dependencies. It would just be a text file in your code base that you hope will run properly in the language server. And if it doesn't work, the language server could crash and you have to figure out what went wrong by digging through language server logs, which most people won't even know how to do, let alone be willing to do.

What might work is to use something like https://esm.sh to dynamically load modules given an identifier in the config. That way the custom dialect implementation would be a dedicated JavaScript project with all the development tools you need for testing and debugging and you can use dependencies if you need it.

But, we have to consider security. Running untrusted code in the language server is inherently insecure. For the most part I think it has the same security implications as any dependency we choose to use. The big difference is that we aren't making that choice, the user is. If we're making the choice, we only add things we think are secure. When the user is making the choice, we could be running anything. So, we have to consider what damage a bad actor could cause?

Vscode allows you to commit your settings, so if someone could get a malicious vocab into the settings, anyone who runs that project with vscode will automatically run that malicious code. It would be tough for security scans to notice because it's just a string in the config.

It could be that the best thing is just to accept PRs to the language server to add support for whatever vocabs and keywords people want supported.

[Adityakumar37]

I think esm.sh is the right call. The idea would be to add a customVocabularies field to LanguageServerSettings as an array of npm package identifiers (e.g. "my-vocab-package@1.0.0"), resolved via esm.sh server-side — so we're not accepting arbitrary URLs. Each package would export a default setup function that calls addKeyword/defineVocabulary/loadDialect, and the language server calls it on init and again whenever config changes.

For security, one option is to only read customVocabularies from user-level settings and ignore it if it appears in workspace settings that way it can't be committed to a repo and silently run on someone else's machine. Not airtight but it removes the main attack vector you mentioned.

Does the general direction look good or do you have a stricter security requirement in mind?

[jdesrosiers]

For security, one option is to only read customVocabularies from user-level settings and ignore it if it appears in workspace settings that way it can't be committed to a repo and silently run on someone else's machine.

I'm not sure it's possible to distinguish between user-level settings and workspace-level settings. Iirc, it all gets mashed together and there's no distinction once it gets to the language server. It also wouldn't be a great user experience.

I wonder if there's a way to prompt the user to confirm if they want to allow downloading and loading the vocabulary with a scary warning. Then remember their response for the future so we don't have to ask every time they load the editor. The hard part is going to be that the confirmation is going to have to happen on the client side while the actual loading would happen on the server. I also don't know what options there might be save the user's response. Maybe you could look into what's possible in those areas.

[Adityakumar37]

Looked into both. For the prompt, window/showMessageRequest works fine the server can send it and await the user's button click without any client-side changes.
For persisting the response, the extension is currently very thin so there's no globalState access from the server side. Two options I can see: store trusted vocab identifiers in a file at a known path like ~/.config/json-schema-language-server/trusted.json which the server reads/writes directly, or add a custom command to the VSCode extension that wraps globalState and have the server call it via workspace/executeCommand. The file-based approach has the advantage of working across all clients including neovim the globalState approach would need separate implementations per client. Does one of those directions seem right to you?

[jdesrosiers]

This is really helpful! window/showMessageRequest and globalState sounds like exactly what we need. I don't think a file is the right choice because files can be committed, which we don't want.

Go ahead with that approach.