Bug 25370 - Create allowlist of plugins allowed to be installed by Web UI
Summary: Create allowlist of plugins allowed to be installed by Web UI
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Plugin architecture (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 25672
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-04 23:38 UTC by David Cook
Modified: 2023-12-14 15:32 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2020-05-04 23:38:31 UTC
This feature would provide a whitelist of plugins that are allowed to be installed in Koha. This whitelist would be managed by some kind of administrator*.

This feature coupled with Bug 24632 would allow Koha users to only installed certain authentic plugins from trusted providers. 

(*I've been thinking that a superlibrarian really should be able to configure all aspects of Koha. However, from a vendor perspective, there are quality of service and security risks that comes with that. So perhaps the administrator level should be configurable. Defaulting to superlibrarian but optionally being switched to backend sysadmin for vendors, so that they can have ultimate say, when running on their own hardware.)
Comment 1 David Cook 2020-05-04 23:42:59 UTC
I am thinking the whitelist would contain an entry like "Koha::Plugin::Com::ByWaterSolutions::CSV2MARC". 

However, another plugin could pretend to be that same one. A malicious plugin could pretend to be a popular plugin and thus defeat the whitelist.

With Bug 24632, that would be far less likely. You could set up your plugin keys so that only Bywater Solutions is trusted, and then only "Koha::Plugin::Com::ByWaterSolutions::CSV2MARC" is allowed on the whitelist. 

It is still possible to have collisions if you trust more than one provider and they use the same name, but that is unlikely due to the naming conventions Kyle created from the start. Different vendors should use their company names like "Koha::Plugin::Com::ProsentientSystems::OaiHarvester" (which one day I hope to be a real thing). 

Plus, if we did start using vendor/community Github/Gitlab as repositories, we could potentially limit the likelihood of people sourcing plugins from obscure locations.
Comment 2 David Cook 2021-12-09 03:23:38 UTC
This looks a bit tougher than I was thinking but should still be doable...

I think if I do a Module::Pluggable search for "Koha::Plugin" in between these following two lines and then compare to an allowlist... that should do the trick.

my $ae = Archive::Extract->new( archive => $tempfile, type => 'zip' );
unless ( $ae->extract( to => $plugins_dir ) ) {
Comment 3 David Cook 2021-12-09 03:33:16 UTC
The challenge is how to define this configuration, but I think I could use the same idea I had at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28498#c4

Set up a configuration file called /etc/koha/plugin-allowlist.yml and then point each Koha instance at that file via koha-conf.xml. That also allows for the possibility to have 99% of instances using the generic allow list while some instances could be configured using /etc/koha/sites/INSTANCE/plugin-allowlist.yml to provide a different list.

(I still want to replace koha-conf.xml, but creating Koha::Config->file() with caching layers is beyond what I want to do right now...)
Comment 4 David Cook 2021-12-09 03:34:58 UTC
I've updated the summary because I think we only need to define an allowlist that inhibits the Web UI. 

I think we should allow sysadmins to install whatever they want.

(I'm also not too concerned with people uninstalling plugins at this point. I think that would be better handled by Bug 28499.)
Comment 5 David Cook 2023-08-17 00:26:52 UTC
Going forward I'll probably just rely on bug 25672 so I doubt I'll work on this...