Question about Snaps

Ralf Mardorf silver.bullet at zoho.com
Sun Oct 9 03:43:30 UTC 2016


On Sun, 09 Oct 2016 04:52:12 +0200, Oliver Grawert wrote:
>hi,
>On Sa, 2016-10-08 at 23:36 +0200, Ralf Mardorf wrote:
>> On Sat, 08 Oct 2016 16:13:29 -0500, Chris wrote:  
>> > 
>> > Some keywords are 'an application with its dependencies', 'secure,
>> > sandboxed, containerized'  
>> 
>> Several security experts consider them as less secure. If everything
>> links against the same library version, it's easy to keep track with
>> vulnerabilities, https://www.ubuntu.com/usn/ , if several snaps use
>> different releases of the same library, it becomes a mess.
>>   
>except that the handfull of the bigger desktop apps on linux do exactly
>this today already, firefox, thunderbird, chrome/chromium, skype, steam
>all build, link and ship their complete set of depending libs today
>inside their deb, libreoffice does this partially ... 

And especially those apps are very often listed as being vulnerable.

>what i find interesting is that you seem to not consider the ubuntu
>security team to be experts (despite using (and obviously trusting)
>their distro and even quoting one of their pages above), note that over
>the last two years quite a big part of their work time went into the
>security design of snaps (and into solutions to issues like the one you
>describe above).
>
>> For a desktop computer there seems to be no advantage when using
>> snaps.  
>
>well, see above ...
>
>and beyond this, actual desktop users don't care what gets installed
>when they pick an app in the software center for installation ...

A lot of Linux users care much about this, let alone that on Arch a
user only need to run a command, to get a list with all vulnerable
packages.

[root at moonstudio weremouse]# systemd-nspawn -qD /mnt/archlinux/ 
Failed to create directory /mnt/archlinux/sys/fs/selinux: Read-only file system
Failed to create directory /mnt/archlinux/sys/fs/selinux: Read-only file system
[root at archlinux ~]# arch-audit -f %n | sort
bzip2
cinnamon-screensaver
gdk-pixbuf2
jasper
lib32-gdk-pixbuf2
libimobiledevice
libtiff
libusbmuxd
libwmf
wpa_supplicant
[root at archlinux ~]#

>ask a mac user what the package format of the apps is that he has
>installed ... 
>
>the same mac user will tell you that he *does* care to have this years
>photoshop edition though, even if his MacOS install is from two years
>ago.

A Mac user isn't a Linux user. We should expect another level of
self-responsibility Linux users, even from those using Ubuntu, let
alone the users of more expert orientated distros.

>> Since Ubuntu provides LTS releases, snaps theoretically could work
>> around issues, if new software is required, but then OTOH to chose a
>> LTS is wrong in the first place. Perhaps a rolling release distro
>> would
>> be the better way to go, if new software is more important, than the
>> advantages of a LTS release.  
>
>LTS releases have exactly one single purpose, enterprise/company usage
>...
>
>normal users want the ability to use newer apps on their OS and dont
>want to be stuck for five years with a missing feature in their office
>suite (that has been implemented 6 months after the LTS came out but
>will only work on the new version of the app). feel free to ask our
>libreoffice team for download statistics of the libreoffice PPA, it is
>probably one of the most used package archives on old LTS installs
>(next to the firefox nightly builds) ... 
>
>maintaining that PPA is a massive pain though.
>while creating a snapcraft.yaml that you can ship in the libreoffice
>git tree after you created it to have your package auto-rebuilt as soon
>as one of the upstream branches of the libs changes (i.e. if it gets a
>security fix) is a one time thing. snaps take a massive burden off the
>developers while at the same time giving users complete independence
>from the underlying distro/release.

Then using a rolling release is the way to go.

>> Communication among different apps is an issue, if each app runs
>> inside
>> its own sandbox/container alike thingy, let alone that until
>> now permissions to use hardware could be tricky, too.  
>
>you might want to read up about snappy's interfaces system, it solves
>such issues in a very elegant and secure way ;)

So there are no issues anymore with e.g. jackd?

>> IOW some of us consider snaps either due to the state of development
>> or
>> in general as bad.  
>
>what exactly qualifies you to make such a judgement ? (given the level
>of knowledge about snaps you expose above)

I'm subscribed to...

>ciao
>	oli
>
>PS: feel free to move on with this discussion on [1], i think it gets
>off topic for ubuntu-users
>
>[1] https://lists.ubuntu.com/mailman/listinfo/snapcraft

...this mailing list and apart from this my main distro is Arch Linux.
I'm only interested in Ubuntu to help computer novices. Outside of the
Ubuntu universe, even those who like an approach similar to snaps, do
not prefer snaps over snap alike competitors, most of the times it's
the other way around, the competitors are more welcome outside the
Ubuntu universe and apart from this most developers have no interested
at all in this approach. I can't provide statistics, but I'm subscribed
to many Linux mailing lists and notice that snap and competitors are
not from interested for the majority of the Linux community.

Regards,
Ralf





More information about the ubuntu-users mailing list