https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24631
--- Comment #17 from David Cook <[email protected]> --- (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. _______________________________________________ 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/
