Consider requiring signatures

[mwadams]

The plugin model allows the tool author to provide a mechanism which continues to enable the independent installation and versioning of components of the command line tool, but presents a unified command line experience over the top of them.

This is not dissimilar to a "master cli program" which orchestrates other cli programs presenting a unified experience over them.

One issue with this parent-and-child relationship is that anyone can add plugins to your CLI tool if they can coerce their plugin into your load space (or replace your child dependency with their own in the master tool, child programs scenario)

I'm highlighting the similarity between the orchestrating-independent-cli-apps and providing-plugins models to highlight that this isn't particularly a plugin model issue, not to suggest that a plugin model isn't necessary. Actually, I think it is a nice way to ship a family of related tools.

What we want to protect against is someone having deployed a bad plugin onto your machine, e.g. from a compromised package download. I don't think we are trying to support arbitrary 3rd party plugins for our tool, although that might be a secondary goal.

If you were to sign the plugins with a private key and validate that key on load you could mitigate a lot of this issue. You would have guaranteed "good" plugins.

You could optionally disable verification (e.g. in config) to allow side-loading of components, and/or use an allow list of keys (i.e. multiple trusted sources) or package name/versions and checksums to side load external plugins.