Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost <tobi@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
Reply to: