[Koha-bugs] [Bug 24631] Plugin metadata should be outside the main class

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

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

--- Comment #17 from David Cook <dcook at prosentient.com.au> ---
(In reply to Martin Renvoize from comment #11)
> As for requiring module load prior to reading the yml.. hmm, does feel like
> we should be able to get that path info from the plugin base code koha side
> somehow.. A chunk of this is actually about how we then expose the new meta
> file next to releases on github (and eventually gitlab) so we can grab that
> data via api's and display/use it prior to install entirely.

The proposed process sounds like how Apt works (ie download and use the
metadata before you even see the packaged software), but you're trying to
shoehorn it into Github/Gitlab infrastructure.

Looking at
https://github.com/bywatersolutions/koha-plugin-kitchen-sink/releases, I see
the koha-plugin-kitchen-sink-v2.1.39.kpz
and PLUGIN.yml sitting next to each other. That means you could download and
verify the metadata without the software, but that would make importing plugins
a 2 step process, if you had to import the KPZ and YAML both. It would also be
possible to load in the wrong YAML file for a KPZ. 

In terms of importing, it would be easier if the PLUGIN.yml were located within
the KPZ file. However, that would require staging and unpacking the file to get
the PLUGIN.yml metadata. Not very API friendly and also a bit fiddly at the
server level. 

Ok I'm having a thought...

If PLUGIN.yml had a MD5 hash for the KPZ file, that would bind together a
PLUGIN.yml file and a KPZ file. (Note that you could cryptographically sign the
PLUGIN.yml file to increase security.) 

To import a plugin, you'd first import the PLUGIN.yml, and then you'd import
the KPZ file (this could be manual or automated).

For backwards compatibility, you could still import a KPZ file without a
PLUGIN.yml. Maybe we could add a system preference for this and slowly
deprecate this functionality. 

For the Upload UI, you could noticeably prompt for the PLUGIN.yml, but have a
small visible link to "skip" the metadata verification process. 

For the Plugin Management UI, maybe it would have to generate plugin metadata
in the absence of the file. It would be less secure, but that's the world that
we're living in at the moment, and we could deprecate this insecure
functionality over time. 

Alternatively, maybe make Koha so that all new plugins for a system have to
have PLUGIN.yml in order to import, but all existing plugins have metadata
auto-generated for them (after all, they're already installed in the system).
And maybe have a system preference to turn off the PLUGIN.yml requirement if
necessary to import old plugins that don't have PLUGIN.yml? That would default
to the safer option while allowing backwards compatibility optionally.

How does that sound?

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