Bug 23890

Questions to note.

1) When/Where should warnings appear?
 - During install, with an abort option?
 - After install, with an uninstall option?
 - Always as a message in the 'installed plugins' table?

I've changed my mind on this one... whilst going through existing hooks and trying to pick which methods potentially exposed us to nefarious code I pretty much decided that they all could.

+    'opac_online_payment'                                 => '1',
+    'opac_online_payment_end'                             => '1',
+    'opac_online_payment_begin'                           => '1',
+    'to_marc'                                             => '1',
+    'edifact_transport'                                   => '1',
+    'edifact_process_invoice'                             => '1',
+    'edifact_order'                                       => '1',
+    'edifact'                                             => '1',
+    'opac_head'                                           => '1',
+    'opac_js'                                             => '1',
+    'intranet_head'                                       => '1',
+    'intranet_js'                                         => '1',
+    'intranet_catalog_biblio_enhancements_toolbar_button' => '1',

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.

(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.
> 

I totally agree with this.

(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?

(In reply to Kyle M Hall from comment #4)
> 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.
> 

As a user/librarian, I think that this sounds awesome.

As a vendor/administrator, I think that this sounds awful.

Since plugins are a stability/security risk, I don't want to allow users to be able to install plugins. That said, I see the utility of plugins, so I - as a system administrator - want to be able to install trusted plugins on Koha (probably from the CLI, since we don't really have an administrator layer in the web UI).

(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.

I envisage somewhat of a mix of the two.. keys administered by system administrators via the command line and searchable repositories via the UI for end users. That combination should allow us to have vendor trusted plugins that are whitelisted at the serverside level but open up the searchability and intallability options to the end users.

I did like the idea of a centralised plugin directory allowing for reviews of plugins and ease of discovery and have had that side of things in mind for a while.. but again, that could utilise a similar philosophy of searching git hosting for plugins that match a certain criteria.

I think the discussion is not if the users can install plugins themselves or not - they already can. This is a discussion on how to make sure they get better information about the plugins and if they are trustworthy. Also allowing admins to whitelist certain repositories... and I think those are good ideas.

I like the idea for the plugins to provide some general information about them. Maybe if we had plugins that were limited to only using what the APIs offer, we could have a list of what they use as an indicator of potential damage. But as our plugins can do 'anything', it's much harder. We could maybe ask developers to include information about data that will be changed by their plugin in some way? A list of core methods and hooks used?

I always liked how the DokuWiki system for plugins worked. They are listed in the DokuWiki DokuWiki, with their repository/zip URLs. Then you can search that from within your own installation, get info and also download and install if a URL has been provided, alternatively, you can still upload zip files manually for installing plugins provided elsewhere. (https://www.dokuwiki.org/plugins)

So maybe we could have a central directory of available plugins with descriptions etc. This would allow us to add a form of rating, QA and similar in the future, but still allowing people to do development using their preferred tool. The DokuWiki directory also allows you to see how often a plugin has been installed by others, as an indicator of those that are popular/widely used. This could be an easy way to have a first indicator of 'quality'. They also include a 'report bugs' link in their directory that is helpful.

As another security measure we could allow admins to 'whitelist' plugins or sources in the directory locally and block the upload of zip files, so users get a limited view of plugins supported/checked by their admins/providers.

I like all those ideas, Katrin. 

Bug 24632 would allow installation of only plugins signed by trusted providers.

Bug 25370 would allow installation of only plugins with certain package names. 

Turning off manual plugin uploads might also be a good idea.