[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

Kyle M Hall <kyle at bywatersolutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kyle at bywatersolutions.com

--- Comment #4 from Kyle M Hall <kyle at bywatersolutions.com> ---
(In reply to Martin Renvoize from comment #2)
> As such, I think warning on some but not others could actually lead us to
> worse situation where inexperienced system administrators are lulled into a
> false sense of security.
> 
> In reality, I feel we need a cleaner delivery method for plugins as a
> community and perhaps a signing procedure to state a certain level of
> trust/quality.  This is something I've wanted to work on for some time but
> not had a moment to implement to date.
> 
> As such, I don't believe this should hold up bug 22706.

I agree. The password hook can clearly be used for nefarious purposes, but
*any* plugin could be bad actor. Outside that hook, all data, subroutines and
methods are available to plugins. I think this is an issue inherent in *any*
pluggable system, Koha or otherwise.

I really like the idea of a trusted plugin authorities with signing. I think we
need to discuss what this will look like, and where we need to start.

I've thought about this a lot over time. I've always imagined a Wordpress like
ability for Koha to search for and install plugins directly from the admin
interface. That still doesn't help us describe a backend for such a system.

I see a few options:
1) Integrate this into Mana
2) Keep it outside Mana, but in another community project
3) A distributed plugin management model

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?

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