Mapper: Offer AppImage, snaps & flatpaks

Created on 24 Jun 2017 · 24Comments · Source: OpenOrienteering/mapper

Offering the new snap & flatpak formats for Linux could allow you. Maybe you can integrate them in your superbuild.

The advantages of snap/flatpak are you only need to support these two distribution types in order to make it available to many distros and they can offer a sandbox for better security.

Source

rugk

Most helpful comment

First the correct word is "insecure". Secondly the link only talks about flatpaks, not snaps. Thirdly that looks like a vulnerability, ~which can be fixed~ which has been fixed as mentioned in the link, you've posted:

Fixed in: 0.8.x >= 0.8.7, all versions >= 0.9.6

But after all, just because there was a vulnerability to escape the sandbox of flatpak/snap, it still means AppImages are way more insecure as they do not have this sandbox at all. So they have full user-rights by default…
So arguing about security does not bring you far, here… :laughing:

rugk on 28 Jun 2017

👍2

All 24 comments

The superbuild solves non-Linux distribution problems by Linux distribution practices (and source packages!). Snap & flatpak are very different from this approach.

Anyway, there is some OBS support for snap:
https://hackweek.suse.com/projects/snap-support-for-obs
https://build.opensuse.org/project/show/home:adrianSuSE:snappy
https://github.com/openSUSE/obs-build/blob/master/build-recipe-snapcraft

and of course
https://snapcraft.io/docs/

dg0yt on 25 Jun 2017

It would be much better use AppImage package

https://github.com/AppImage

Cast @probonopd

Symbian9 on 28 Jun 2017

👍2 👎1

Why better, no? AppImage is also a possibility, but it does e.g. have no possibility to sandbox the applications.

rugk on 28 Jun 2017

https://github.com/AppImage/AppImages/issues/249

Symbian9 on 28 Jun 2017

👎1

Why better, no?

@rugk, because snap & flatpack are unsecure!

http://seclists.org/oss-sec/2017/q2/569

but it does e.g. have no possibility to sandbox the applications

What you mean under 'sandbox' for OOMapper?

https://en.wikipedia.org/wiki/AppImage

Symbian9 on 28 Jun 2017

👎2 👍1

Fixed in: 0.8.x >= 0.8.7, all versions >= 0.9.6

rugk on 28 Jun 2017

👍2

which has been fixed as mentioned in the link, you've posted

It was fixed only few days ago, and nobody know did flatpack not include today.

snap is fully Ubuntu project, that could be dropped in any time (R.I.P. mir... Hello, GNOMEbuntu!)

AppImage already used by Scribus, Krita and many other major open-source projects

https://github.com/AppImage/AppImageKit/wiki/AppImages

Symbian9 on 28 Jun 2017

👎1 👍1

It was fixed only few days ago, and nobody know did flatpack not include today.

This applies to any vulnerability. And in every software vulnerabilities exist. And we don't know the state of AppImage.
As said, security is not a good argument here, so you've switched to different ones.

snap is fully Ubuntu project, that could be dropped in any time

Aha, well…, there is always someone who continues/forks it, but I doubt it will be dropped so fast. ANd if they do, then maybe in favour of flatpaks… :wink: So use them then.

AppImage already used by Scribus, Krita and many other major open-source projects

Sweet, and how does this affect this project?
And here are some flatpaks. Note that in addition to many GNOME applications, Blender, and… uh… Skype and Spotify uses it… http://flatpak.org/apps.html

Searching for snaps I just experienced is horrible as there are all kind of other software with this name… (even some dinosaurs they should really have choosen another name), but here are some images of popular snaps.

In any case we don't need to argue what is better. It likely also won't matter… Of course this can be packaged as appimages and as snaps and as flatpaks. Letting the user to choose what/how to install it, is always good.

rugk on 28 Jun 2017

So much noise, and little of this touching my personal concerns as a user or developer, such as security updates of dependencies, or licensing compliance.

But looks like there is also a link between OBS and AppImage:
https://github.com/AppImage/AppImageKit/wiki/Using-Open-Build-Service
https://build.opensuse.org/package/show/home:probono/QtQuickApp

dg0yt on 29 Jun 2017

So much noise, and little of this touching my personal concerns as a user or developer, such as security updates of dependencies, or licensing compliance.

And these slides cover it very well:
https://speakerdeck.com/sysrich/opensuse-conference-2017-the-t-rex-was-the-hero-of-jurassic-park#

dg0yt on 29 Jun 2017

👍1

https://github.com/OpenOrienteering/mapper/pull/898 builds and uploads an AppImage for each git push. Using OBS would be another option, if you prefer that.

probonopd on 29 Jun 2017

For the record, I want to repeat here (from #898) what needs to be known or solved for these kind of packages before we can distribute them:

The resulting package is large (54 MB now for AppImage at OBS), much more than our other image-style packages. This is due to more numerous and complex dependencies, especially for Qt Assistant/WebKit and for gdal. This can only be reduced if we build the libraries ourselves. Well, we have got the tool (superbuild).
The licensing of all the bundled libraries needs to be reviewed, and documentation needs to be added to the AppImage as needed. We have got the Infrastructure ("licensing provider" stuff in doc/licensing), but it is a lot of work, given >100 libraries. Again, using our superbuild could help with the effort, by reducing dependencies and using Debian copyright files.
Where Mapper uses resources which are distributed inside the package, we need to make sure that it really picks up resources from the package. Also resources for Proj.4 and GDAL need to be handled.

dg0yt on 2 Jul 2017

The resulting package is large (54 MB now for AppImage at OBS)

Can you give direct link to this AppImage?

Symbian9 on 12 Jul 2017

This AppImage is not published for the reasons given.

dg0yt on 12 Jul 2017

👎1

For the record, this is the list of libs in the 33.2 MB AppImage if NOT deploying Qt Assistant (WebKit). The checked libraries are the ones which are build with superbuild for non-Linux systems. (On the other hand, some libraries seems to be alternative to the ones we use in superbuild, such as libxml2 <-> expat.)

[ ] libavahi-client.so.3
[ ] libavahi-common.so.3
[ ] libbz2.so.1
[ ] libcrypto.so.1.0.0
[ ] libcups.so.2
[X] libcurl.so.4
[ ] libdbus-1.so.3
[ ] libffi.so.4
[ ] libfreetype.so.6
[ ] libfreexl.so.1
[X] libgdal.so.1
[ ] libgeos-3.4.2.so
[ ] libgeos_c.so.1
[ ] libgeotiff.so.2
[ ] libgif.so.6
[ ] libglapi.so.0
[ ] libgraphite2.so.3
[ ] libharfbuzz.so.0
[ ] libhdf5_hl.so.10
[ ] libhdf5.so.10
[ ] libhdf.so.4.2.11
[ ] libicudata.so.52.1
[ ] libicui18n.so.52.1
[ ] libicuuc.so.52.1
[ ] libjasper.so.1
[ ] libjbig.so.2
[X] libjpeg.so.8
[ ] liblber-2.4.so.2
[ ] liblcms2.so.2
[ ] liblcms.so.1
[ ] libldap-2.4.so.2
[ ] libldap_r-2.4.so.2
[ ] libltdl.so.7
[X] liblzma.so.5
[ ] libmfhdf.so.4.2.11
[ ] libmng.so.1
[ ] libmysqlclient.so.18
[ ] libnetcdf.so.7
[ ] libodbcinst.so.2
[ ] libodbc.so.2
[ ] libopenjp2.so.7
[X] libpcre16.so.0
[X] libpcre.so.1
[X] libpng16.so.16
[ ] libpoppler.so.44
[ ] libpq.so.5
[X] libproj.so.9
[X] libQt5Core.so.5
[X] libQt5DBus.so.5
[X] libQt5Gui.so.5
[X] libQt5Network.so.5
[X] libQt5PrintSupport.so.5
[X] libQt5Widgets.so.5
[X] libQt5XcbQpa.so.5
[ ] libsasl2.so.3
[ ] libspatialite.so.7
[X] libsqlite3.so.0
[ ] libssh2.so.1
[ ] libssl.so.1.0.0
[X] libtiff.so.5
[ ] libwebp.so.5
[ ] libX11-xcb.so.1
[ ] libXau.so.6
[ ] libxcb-dri2.so.0
[ ] libxcb-dri3.so.0
[ ] libxcb-glx.so.0
[ ] libxcb-icccm.so.4
[ ] libxcb-image.so.0
[ ] libxcb-keysyms.so.1
[ ] libxcb-present.so.0
[ ] libxcb-randr.so.0
[ ] libxcb-render.so.0
[ ] libxcb-render-util.so.0
[ ] libxcb-shape.so.0
[ ] libxcb-shm.so.0
[ ] libxcb-sync.so.1
[ ] libxcb-util.so.1
[ ] libxcb-xfixes.so.0
[ ] libxcb-xkb.so.1
[ ] libXdamage.so.1
[ ] libxerces-c-3.1.so
[ ] libXext.so.6
[ ] libXfixes.so.3
[ ] libXi.so.6
[ ] libxkbcommon.so.0
[ ] libxkbcommon-x11.so.0
[ ] libxml2.so.2
[ ] libxshmfence.so.1
[ ] libXxf86vm.so.1

Looks like there won't be printing without CUPS, which in turn requires OpenSSL or similar... I'm not going to spent more time on this.

dg0yt on 17 Jul 2017

I don't understand what the problem is. What don't you want to spend more time on? Can I help?

probonopd on 24 Jul 2017

See what I wrote before:

The licensing of all the bundled libraries needs to be reviewed, and documentation needs to be added to the AppImage as needed. ... it is a lot of work, given >100 libraries.

This is due to the fact that distributing shared object files is subject to common terms such as

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.

And this review has to be repeated for each binary component which is updated. This is different from regular Linux packages, where binary components are distributed independently, packaged with the required documentation.

What would help is if the AppImage tools would not only copy shared objects, but also copyright files. (And that's what we do for our non-Linux packages.)

In addition, since Mapper is GPL V3 licensed and the listed libraries do no longer constitute system libraries when bundled in the AppImage, we we must consider the libraries' source code as being part of the Corresponding Source which must be provided in certain ways (GPL V3 section 6). This will be even more work than adding the documentation!

So I decided to not spent more time on this because it would continuously consume too much of my precious time for the development of the app, while acceptable alternative solutions do exist. (OTOH I didn't close the ticket as wontfix, and the AppImage recipe is available on OBS.)

dg0yt on 24 Jul 2017

I was about to say, OBS can take care for much of this for you... thanks for your detailed explanation.

probonopd on 24 Jul 2017

OBS can take care for much of this for you.

As OBS currently is not automated, lets add AppImage build to superbuild for autobuild each dev pre-release for Linux.

https://github.com/probonopd/mapper/blob/patch-2/.travis.yml
- https://github.com/probonopd/mapper/releases/tag/continuous

Symbian9 on 24 Jun 2019

@Symbian9 Probonopd's contribution is tracked in #898. The lack of an AppImage offer from OpenOrienteering is not due to the lack of OBS automation. The biggest piece of work to be done is verifying the legal terms and attributions which needs to be part of this package. It is more than for other platforms (see above).

dg0yt on 25 Jun 2019

The lack of an AppImage offer from OpenOrienteering is not due to the lack of OBS automation.

Hi @dg0yt is OBS a must for an AppImage of OpenOrienteering to be produced? Please comment in my PR which has not been merged for 2 years.

probonopd on 28 Jun 2019

👍1

BTW in flatpak you have the concepts of runtimes, which are independently installed "base images" with most common software. As these may include much software, that would likely solve: