Provide clear guidance on avoiding security problems with `template` type package arguments

[tadasant]

@alexhancock brought this up #33 (comment):

what validations would we imagine for template strings? Both for validity but also command injection. For example, what would we do if someone submitted a server with:

"template": “;rm -rf ~/Development”

@connor4312 said:

In general we have to assume that clients do the right shell escaping for arguments (or don't run the in shell, e.g. child_process.spawn). Users can do very valid things like put in quotation/punctuation marks and spaces into arguments, and if the client runs them in a shell it takes on the responsibility of escaping those.

It'd be helpful to get some more thoughts on whether we have a potential security hole here, and what kind of formal guidance we can issue to clients (and/or SDK features we can implement) to mitigate any potential damage.

[alexhancock]

I think there are (at least) two questions to consider

1. Should the registry do any form of scanning/sanitizing of the input if we do choose to enable the template field?
2. What should we document about the risks client developers face when constructing commands from the template value and through what documentation channel?

@connor4312 per the original exchange in #33, I agree about shell escaping being a client responsibility before running, but I worry more about malicious commands being included, like the example:

"template": “;rm -rf ~/Development”

Are you thinking about this in a different way? Is there something I am missing in the design of the feature that makes this not a risk?

[connor4312]

Should the registry do any form of scanning/sanitizing of the input if we do choose to enable the template field?

This is nice but not possible to do with complete accuracy -- this is the halting problem. And folks could always just have a command that gets a shell script from the web and install that way, which is a popular approach for some packages in general, though we could have some LM analysis step as part of submission to provide a rough safeguard (provided the false positive rate is acceptable.)

What should we document about the risks client developers face when constructing commands from the template value and through what documentation channel?

I'm not sure where such instructions should exist, but I think we can recommend that "Clients MUST display the command(s) use to execute an MCP server to users and obtain their consent before executing commands from new servers or new server versions."

Is there something I am missing in the design of the feature that makes this not a risk?

Notably, MCP server commands don't have to be executed in a shell. And I think spawning in a shell is actually pretty rare because clients need direct stdin/stdout access. If clients used posix_spawn or equivalents then there is no risk of injection.