Snappy Packaging Happenings In The Fedora, Arch Space

[profoundWHALE]

I hope to see these turn out to be (for the end user) like .exe and .msi packages are on Windows in the sense that installing something is easy. No more dependency hell please!

[theghost]

What about CLA-signing for code contributions to Snappy? Is it still a must ?

[DrYak]

I hope to see these turn out to be (for the end user) like .exe and .msi packages are on Windows in the sense that installing something is easy. No more dependency hell please!

That's the purpose of both, with subtle details in the implementation

With Snaps containing the whole kitchen sink of every lasr single .so dynamic library that a piece of software might cal into (hence the giant GB-sized LibreOffice snap)
(This is somewhat reminiscent of the good old dos-gamimg days, where every gmaes came packaged with all its things included together)

And Flatpak defining a set of basic libraries and versions that should be available on any Flatpak-compliant distro and installed together with the flatpak support, and can be targetted by the software developers. (Thats similar to how Steam for Linux comes with a set of libraries, that can be targeted by the port,no matter which distro it is running on).
(Its also distantly reminiscent of how Windows and Mac OS X work by giving a fixed and known list of deps to work with)

Now whether this idea is good is an altogether different question.

My opinion is that this gives some solution for the developers of closed-source software (with Steam having set a nice precedent).
But for anything else where the source is available, 3rd party packge repositories like Suse's Openbuildsys, or Ubuntu's PPA are the superior approach.

My main complain about this paks approach is that this results in increased vulnerabilities due to duplicated dynamic libraries everywhere.
Compare a vulnerability in Linux: openssl was crappy, but it got fixed. You just upgrade your systems' main copy in /usr/lib(64) and you're good to go. It gets fixed once for all.
Compare a vulnerability in Windows: WMF handler has proven to be exploitable for arbitrary execution (or the tiff handler is exploitable for out-of-band access). Now the copy of .DLL that every single needs to be upgraded to patched version. Some developers haven't provided any upgrade. Some developers don't exist anymore. You might have patched all microsoft software (e.g.: ms office), but there is still an obscure old tool that is vulnerable.

[justmy2cents]

They will certainly enable it, there is no reason not to, I believe all distributions will support both snaps and flatpaks, everyone will benefit from them.

you should read comments from Fedora ppl. not very likely OTB would happen. no real enthusiasm there

there is no reason for distros that don't bet on any solution, Fedora is making bet on flatpak. enabling it by default without ubuntu doing the same for flatpak would practically spell the flatpak being downgraded as secondary choice since it doesn't work everywhere.

[Mystro256]

That's the purpose of both, with subtle details in the implementation

With Snaps containing the whole kitchen sink of every lasr single .so dynamic library that a piece of software might cal into (hence the giant GB-sized LibreOffice snap)
(This is somewhat reminiscent of the good old dos-gamimg days, where every gmaes came packaged with all its things included together)

...

My main complain about this paks approach is that this results in increased vulnerabilities due to duplicated dynamic libraries everywhere.
Compare a vulnerability in Linux: openssl was crappy, but it got fixed. You just upgrade your systems' main copy in /usr/lib(64) and you're good to go. It gets fixed once for all.
Compare a vulnerability in Windows: WMF handler has proven to be exploitable for arbitrary execution (or the tiff handler is exploitable for out-of-band access). Now the copy of .DLL that every single needs to be upgraded to patched version. Some developers haven't provided any upgrade. Some developers don't exist anymore. You might have patched all microsoft software (e.g.: ms office), but there is still an obscure old tool that is vulnerable.

Well non-debug libre office snap wasn't actually anywhere near a gig in size (like i think 100mb above the flatpak, note that the debug one was the 1 gig snap), but I completely agree with you when it comes to security concerns. I feel like flatpak has a better solution here, as it reduces the duplication a bit, which is better for size and security patching.

[DrYak]

but I completely agree with you when it comes to security concerns. I feel like flatpak has a better solution here, as it reduces the duplication a bit, which is better for size and security patching.

Yup, it's
- update 'flatpak-base.rpm' (or whatever is the equivalent of steam.rpm in the flatpak world)
vs.
- update every single last snap (which might not by 1Gig, but is still very big) affected by the bug

The former is definitely both simpler and a much smaller attack surface than the later.

(And either is beaten by "simply update '{buggy-package}.rpm' and all package referencing it will be secure (don't forget to restart software already running)".
But that requires availibilty of the code, so that the software referencing it is simply an RPM which is part of your base distro or automatically built by a 3rd party repo maintainer, instead of a binary monster released by the developer)

[mhall119]

Yup, it's
- update 'flatpak-base.rpm' (or whatever is the equivalent of steam.rpm in the flatpak world)
vs.
- update every single last snap (which might not by 1Gig, but is still very big) affected by the bug

Both flatpak and snaps have a shared "base" that all the apps use. If the software that needs updating is in that base, then for both flatpak and snaps all you have to update is the base. If the software that needs updating is not in the base, then for both flatpak and snaps you need to update each app that includes it. There is no difference between the two solutions when it comes to this.

[Mystro256]

Both flatpak and snaps have a shared "base" that all the apps use. If the software that needs updating is in that base, then for both flatpak and snaps all you have to update is the base. If the software that needs updating is not in the base, then for both flatpak and snaps you need to update each app that includes it. There is no difference between the two solutions when it comes to this.

I'm pretty sure he/she's talking about the flatpak runtime. Does snap have a runtime? Because this is the first I've heard of this.
I was under the impression that snap had minimal runtime while flatpak provided quite a few libraries to be shared by the flatpak apps (GTK for example). A runtime like this means smaller package sizes and easier to patch for security issues, as less static libraries are required.

[telemachuszero]

I'm pretty sure he/she's talking about the flatpak runtime. Does snap have a runtime? Because this is the first I've heard of this.
I was under the impression that snap had minimal runtime while flatpak provided quite a few libraries to be shared by the flatpak apps (GTK for example). A runtime like this means smaller package sizes and easier to patch for security issues, as less static libraries are required.

Apparently it does have features that enable runtime-like snaps, and KDE and ElementaryOS plan on releasing their apps + 'runtime' snap for them - from the linked mailing list post:

Runtimes are supported in snaps. While technically there's no specific "type" of snap, it's possible to build a snap that contains common libraries and services that can be connected to other snaps. This is done through the "plugs" and "slots" that can be used to create interfaces among them. This is a true superset of the capability provided by Flatpak through Portals, since it can be used to export non-DBus oriented communications mechanisms. This is described on the Snapcraft documentation[0].

[Mystro256]

Apparently it does have features that enable runtime-like snaps, and KDE and ElementaryOS plan on releasing their apps + 'runtime' snap for them - from the linked mailing list post:

Oh nice, I hope they adopt using this then; not having this could turn into a security nightmare .