Plugin maintenance, security and governance

[HadjievK]

As the plugins can contains skill from vendor A, another skill from vendor B, mcp from Vendor C and another mcp from vendor D thats open the question for versioning, maintaining and compliance of the Plugins.

Plugins should refer and describe which versions exactly contains for each skill and mcp.

Also the plugin needs to carry updates of the skills/mcp.

And of course security. Install a plugin which contains tens of skills and tens of mcp is a dangerous and risky.
A good idea could be to have like a tag “verified” which indicates a certain skill or mcp is verified and secure.

Happy to see this project and I am willing to help and contribute!

Enjoy! 🤝

[bobleer]

The verified label is probably three separate claims: who published it, whether the bytes match what was reviewed, and what capabilities it can exercise. A signed package can still be dangerous, and a reviewed v1 says nothing about v1.1.

In BitFun we ended up importing hooks as immutable snapshots, showing source changes before an update, keeping project hooks off by default, and letting a hook narrow permission policy but never widen it. I would like the package format to carry version + digest + publisher identity, while the host owns capability grants and shows the install/update diff.

That makes “verified” something a user can actually inspect instead of one reassuring badge covering four different risks.