[Koha-devel] Plugin Security, Plugin Repositories, etc

[dcook at prosentient.com.au]

Hi all,

 

I was doing my morning reading, and noticed that Microsoft have a Windows
Package Manager in the works
(https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manag
er-preview-download). While that might not be newsworthy for many people
interested in FOSS, you might reconsider when you look at what they're doing
for a community metadata repository:
https://github.com/microsoft/winget-pkgs  

 

Here's an example of a metadata file for 7-zip in that repository:
https://github.com/microsoft/winget-pkgs/blob/master/manifests/7Zip/7Zip/19.
0.0.yaml. It includes a URL to the installer and a SHA256 hash for integrity
checking. 

 

Now according to https://github.com/microsoft/winget-cli, it doesn't look
like they're using that Github repository as *the* metadata source
repository. Indeed after a bit of digging it appears that the actual default
metadata source is https://winget.azureedge.net/cache/source.msix, which
contains a SQLite database of metadata (index.db). 

 

I think that's an interesting model. We could use
http://gitlab.com/koha-community/plugins like
https://github.com/microsoft/winget-pkgs  where people could submit pull
requests to get plugin metadata added to the repository. That would enable
there to be a basic level of curation. We could then use something like
https://plugins.koha-community.org/ to serve actual metadata (in whatever
standardish format we want) to either the Koha web UI (and a Debian package
Koha CLI tool like "koha-plugin-get" which make plugin deployment and
maintenance potentially easier for sysadmins). There could be an automated
process for updating plugins.koha-community.org from
http://gitlab.com/koha-community/plugins too. 

 

People would be free to point to other plugin metadata repositories (e.g.
vendor-specific repos), but by default it would be set up for the Koha
Community plugin metadata repository. 

 

In terms of security, we could mimic Debian's Apt model of signing the
plugin metadata manifest. That way, when setting up a plugin metadata
repository in Koha, all you need to do is import a public key/cert to get
trusted access to the repo. With the Koha Community repository, we could
bake that public key/cert into Koha releases, so it would be seamless for
end users.

 

The hardest part of this process would be settling on what metadata manifest
format to use for https://plugins.koha-community.org/. 

 

Actually, the hardest part would be trying to maintain some kind of backward
compatibility. Maybe that's best done by rebranding the current plugin model
as "Legacy Plugins" or "Manual Plugins" and then just building a separate
web UI for the Repository model. We could re-use the same internals. We
could also have separate controls for enabling/disabling "Manual Plugins" vs
"Repository Plugins", so that vendors could provide access to plugins via a
repository but prevent people from uploading random plugins from the
Internet. 

 

Anyway, food for thought. I'm happy to do a lot of this work (probably in my
personal time rather than work time), but I'd want to make sure there is
some buy-in from other vendors and Koha plugin creators first. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200522/c10c73e7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200522/c10c73e7/attachment.sig>