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