On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost <t...@debian.org> wrote:
> > Not really. Do you think a patch is motivated? If so, for each and every > > plugin, or just for the first one? > > I'm not sure how plugins are installed. If there is an UI, the warning > could be presented in that gui. The basic workflow is similar to the browsers: User sees a list of possible plugins, points to plugin to install, it's downloaded and installed. It is certainly possible to patch this with a dialog showing some info, for example for the first installed plugin. I know the code good enough to make such a patch. All this said: do you think it's motivated to make such a patch? > I meant with Man in the Middle: There would be many possiblities for attacks… > If they are not protected by e.g a checksum, Malice one could > replace them, either in the repo or in transit. There is no gurantee > that binaries match the sources, as well, if not build in trusted enviorments > or somehow signed. … Checksum/signing is definitely on the agenda, the plugin system is still not mature. That said, as of today I think an attack needs to hijack either a github url (for the catalog) or some url on the cloudsmith deployment server. While certainly possible, it's probably not trivial To be honest, this is probably not the biggest attack surface on opencpn > "tight control upstream" somehow sounds that you control what plugins > can be installed. Just to make sure that we cover all those freedoms > we care about: I can have my own plugin installed, right? Yes, using an import function any plugin can be installed from disk. > OK, maybe, I'm not a user, so I can't tell. > However, you don't likely need _all_ plugins packaged… Focusing on the other aspect: the workflow (think of the browser's plugin systems) is really hard to implement when installation requires root privileges. Thinking about it, it might be possible to install from a .deb package, basically "downloading" from /usr/lib instead of an url. Might be worth an upstream bug. Not sure how much user-value this would add, though. Will file upstream bug. > Packaged plugins have advantages too, because > the packaging system can be your friend: We have had these discussions in depth. Also, as you might noticed, I'm not completely new to packaging. Yes, they have advantages. But in the opencpn context the cons weighs more. It's the combination of user experience, the need to install as a regular user, multiple linux distros and administrative work. It's certainly not a binary black and white decision. But, it is a decision. > How are you planning to support all the architecures Debian supports? The plugins uses a CI build chain which supports the core architectures. Plugins are built and uploaded automatically. They become available to users when url and metadata is included in the catalog -- this is semi-automatic process ending up in a PR against the catalog. > Welcome, and sorry for being too Debianite ;-) No need for apologies, discussions are always good. If I required an apology for these remarks I should probably not be in this business...:) As a result I will file two upstream bugs. And perhaps make a patch, if you deem it motivated. All good things. > Your plugin approach is not how we usually do things here… I know. But still not unheard of, the browsers comes to mind. Now, I need to do some work. Will unfortunately not happen today, need to prepare for work tomorrow. Cheers! --alec
