Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, Sep 08, 2020 at 08:10:48PM +0200, Alec Leamas wrote:
> 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 guess. (Again being Debianite ;-))
Debianites are generally very sensitive about privacy, so any feature that
"calls home"* feature is usually frowned upon; And this is kind of a side
effect of a plugin manager that pulls stuff from the Internet…
(* is is not uncommon that call home features (sometimes just called "check for
updates") are patched away in Debian)
>
>
> > 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
(It happened before that binaries were replaced by an attacker and served
malware to people for quite a time until people noticed.
Through being hacked or just through weak credentials.)
>
> > "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.
Hows about having two locations to look at plugins when loading them?
(This is how e.g gnome-shell does it)
As a side bonus, this would allow people to package plugins indepedently.
>
> > 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.
Yes, I read the bug report. However note that there is not only Debian and
Ubuntu, there are very many Debian-derivates that just pull packages from Debian.
Do you want to have meta data for each of them?
> 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.
For Debian core architecures means
https://wiki.debian.org/DebianBuster#Architectures
>
> > 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.
Browsers are completly different beasts, in terms of complexity, difficult
upstream, etc… They have some specialities which are grudgingly accepted,
because of no other choice. And yet, there are quite a few browser extensions
accepted.
> Now, I need to do some work. Will unfortunately not happen today, need
> to prepare for work tomorrow.
Have fun and dont worry; we are all volunteers here ;-)
--
Cheers,
tobi
> Cheers!
> --alec
>
Reply to: