https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23890
Kyle M Hall <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Kyle M Hall <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
