[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 #18 from Kyle M Hall <kyle at bywatersolutions.com> ---
(In reply to David Cook from comment #17)
> (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?

Those are some good ideas, a lot of which are more in the scope of
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24632

Take a look at that bug and file a bug that depends on both of them both that
would add the missing pieces!

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