[Koha-bugs] [Bug 23890] Plugins that utilise possibly security breaching hooks should warn

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890

--- Comment #6 from David Cook <dcook at prosentient.com.au> ---
(In reply to Kyle M Hall from comment #4)
> 3 is what I keep coming back to in my mind. What I imagine is an interface
> in Koha to define plugin repositories. I think we could leverage the release
> systems in GitHub and GitLab to power such a system.
> 
> So, for example, if I want to be able to search and install plugins from
> ByWater Solutions, I'd add https://github.com/bywatersolutions/ to my plugin
> source targets. Koha would then search for repos prefixed with "koha-plugin"
> ( which seems to be a general convention followed by most plugin developers
> ). At this point it would be trivial for Koha to pull data about the plugin
> from GitHub. One addition to plugins that would facilitate this is to add a
> package.json file with contents similar to what is in the metadata of the
> plugin file removing the need to download the plugin to know metadata about
> it like the supported Koha versions. Indeed, it would allow Koha to skip
> over plugins that are known to not work with that version of Koha!
> 
> The same could be done for GitLab I'm sure.
> 
> Thoughts?

I don't really like the sound of that, as it seems hacky and too Git-specific. 

Maybe we should look around at other examples before we re-invent the wheel?

I will just note that I envision a system where we have a list of public keys
and a list of repositories (quite like APT really). You search the repository
and when you try to install a plugin, you check the plugin file's signature
against the public key, and only verified plugins are installed.

-- 
You are receiving this mail because:
You are watching all bug changes.