Thanks everyone for the feedback so far. From our discussion I'm putting below the requirements for a plugin repository. I think the most important question now is what information exactly a developer should provide.
Developers submit or update a plugin by creating a pull request
That's the easiest way both for us and developers.
Plugin location provided by developer should be immutable
In other words the content pointed by that reference should not change once it's in our repo. We still need to define what exactly the developer should provide - release URLs, tags and commits aren't good because the content pointed by them can be changed.
Optionally, developer should provide a tag or commit associated with the JPL file
So that it can be built and checked independently. Not necessarily by us, but reproducible builds are important to prove that nothing suspicious has been added to the minified JPL code.
It should be possible to access the manifest file
The client will need to access the manifest file, which is inside the JPL code. Downloading all the JPL files to get that info is not ideal, so that manifest file should be obtainable from somewhere else. If the developer provides a GitHub URL, we can find it in src/manifest.json for example.
Security policy
We cannot possibly review all plugins, just like Homebrew for example is not going to check every single package. However we can enforce important checks via the immutable URLs mentioned above, the ability to build the plugin independently, and generally a transparent process with the way plugins are added or updated in the repo.