Ubuntu 16.04 LTS Will Bring Snap Packages For Up-To-Date, More Secure Apps (neowin.net)

An anonymous reader points us to a report on Neowin: Canonical, Ubuntu's parent company, has announced that Ubuntu 16.04 LTS (Long Term Support) will come with support for the snap packaging format and tools. As a result, end users will get more up-to-date apps, something that proved tricky in the past due âoethe complexity of packaging and providing updates,â which prevented updates to some apps being delivered. Snaps will make the Ubuntu platform more unified, developers will more easily be able to create software for PC, Server, Mobile, or IoT devices. The other major benefit of snaps is that that they're more secure than software installed through deb packages. Snaps are isolated from the rest of the system, meaning that malware packaged with a snap won't be able to affect your Ubuntu installation.

Comments

Like Static Linking!

[TechyImmigrant]

This is like static linking. Just link in all the code from all the libraries your program uses. Back to the simple life.

Another outbreak

[edittard]

Another outbreak of â disease.

Re:Another outbreak

[rtkluttz]

Yes... it looks like just another implementation (outbreak) of an app store. An app store where "security" means secured against us (the owners of the devices and computers) more than against any bad actors. I hope to be proven wrong, but that is usually where these sandboxed environments end up.

Why?

[binarylarry]

When you think about what sucks in Ubuntu right now, are apt and deb really the worst offenders that need work?

Re:Why?

[NotInHere]

I see one advantage in snap apps. The current situation is depicted in this nice xkcd https://xkcd.com/1200/ perhaps in the future we will have more isolated applications.

Re:Why?

[SumDog]

Exactly. Package management with dependencies is what Linux does RIGHT! Look at Android and it's horrible "you have to update the whole damn firmware because nothing is managed by packages!"

Apks and MacOS app containers add so much redundancy. If you have a library with a security problem, you can now have 50 of that library with a security problem scattered everywhere. In the Linux world with proper package management, if develops use the system libraries, then their apps get those security updates.

Re:Why?

[fisted]

The same way it interferes with your redundant RAID array.

Re:Why?

[Junta]

Except this is more about isolating their on-filesystem footprint, but they still at runtime pretty much have run of things. So a package can't 'update' the system-wide openssl with a malicious version as a side-effect, but it still could happily access files in your home directory to be able to log on to whatever (also could lay down a library in user directory and manipulate LD_LIBRARY_PATH for children so it could try to opportunistically spawn a browser with a different library path to be nefarious)

Conversely, you *cannot* apply something like an openssl update that would apply across the board using 'snap', and any effort to do so with deb would be ignored by 'snap' packages.

Re:Why?

[binarylarry]

The answer to the comic's problem isn't a new package manager, it's two factor authentication.

Re:Why?

[RabidReindeer]

Whatever you're smoking is something that's stronger than anything legal in Colorado.

Third party app packaging support for Linux is something that's been around for ages. RPM for Red Hat and friends, dpkg for Debian/Ubuntu, and other lesser-known facilities for other systems. In actuality, probably 80+ percent of the stock repositories of the popular Linux distros are "third party" apps which have been built as distro-specific system packages - they're just part of the official repos, that's all. Other than that, packages I design and build myself of my own apps install and are managed in exactly the same way.

If your complaint is with dependencies, the main repository systems handle that as well. How well a given app will deal with dependencies depends on how well the package maintainer defined its needs, but the installers can do a very good job of making things "just work".

This "monolithic dependency tree" thing you're talking about doesn't even make sense to me. A YUM repo has had its packages scanned by a tool that constructs a dependency database in order to make dependency resolution faster, but by that definition, any read-mostly database is a "monolithic depency tree" or something similar. And you can't just jam in your own package to someone else's repo. The repo servers are designed to permit only authorized personnel to add packages and update the dependency database and to declare via appropriate signatures that assure that the repo isn't being circumvented.

If you use a random third-party repo, you are at risk, yes, but every repo is a risk. It's just that some repos have public trust and others depend on faith. If I was to set up and host repo, it would have the same security capabilities as the master Debian repos, just not the widespread faith.

Now if you want to talk about the problems that come from mixing dependencies from multiple repos where the dependencies were built with different capabilities, that's another issue entirely. There is, unfortunately, no real way to tell if a given repo's version of mencoder comes standard with the codes that my package might require. And it would be an interesting challenge to be able to resolve a problem like that, considering that every app (third party or not) could have a different collection of features and capabilities to be added, excluded or interfere with each other.

Re:Why?

[Kjella]

When you think about what sucks in Ubuntu right now, are apt and deb really the worst offenders that need work?

By far no. But sometimes all those dependencies drag you into cascading updates that you don't want. Like I once wanted a new feature in KDevelop, but really I didn't want to touch the rest of my KDE apps because they were working fine. But KDevelop insisted on updating the KDE libraries, which lead to apt-get insisting on new versions of almost everything. If a "snap" could let me install that one application in isolation that's certainly a feature I could like. And maybe the other way around too, if I really don't like the way an application f*cked up their UI I can easily run an old version without conflicts and complaints because I had to pin a package and thus all its dependencies too. I wouldn't want every package to be like that, but when it's the right tool for what you want it seems useful.

Re:Why?

[hitmark]

Yes and no.

The basic problem with deb, and rpm, and similar package manager, are that they get hung up on the package name and version.

Meaning that you can only have one version of a particular name installed at any one time.

Want to install another version? Either you remove the old version or you change the name to avoid a conflict. But changing the name plays havoc with the dependencies tracking.

If deb and/or rpm was changed so that the manager could handle tracking multiple versions of the same package name, the need for the likes of snappy, xdg-app, or a myriad of similar systems would not be needed.

You can see this if you check out NixOS/Guix or Gobolinux that have implemented slightly different solutions to the same problem.

Re:Why?

[Anonymous Coward]

It's not about the 3-5 MB (though in many cases we are talking more like 10-30 MB per app, which quickly ends up several GB overall), but as said in the previous post about the 100s of security holes that will be updated months late if ever.
I.e. it brings the Android model of security (which is: just close your eyes hard enough to not see the holes) to Linux.

Re:Why?

[Anonymous Coward]

Packaging format is not an impediment. Nothing prevents you from installing your app and all its dependencies into a subdirectory like /opt/my-project and distributing a tarball. Using the ELF ${ORIGIN} linker macro, you can even ship subtrees that can be transparently moved around as a bundle anywhere on the filesystem, just like OS X applications. So, for example, you could create my-project.zip or my-project.tgz that unpacks to my-project, and reliably execute the binaries straight out of my-project/bin regardless of where you unpacked my-project/, and without static compilation.

glibc has excellent ABI compatibility. It makes extensive use of ELF symbol versioning, which puts it lightyears ahead of Visual Studio's CRT and is much better than Apple's awkward MACOSX_DEPLOYMENT framework. So you don't need to statically compile libc or ship your own copy, as people often did 10+ years ago.

The persistent problem is that there's no single Linux platform. Not only are there myriad distributions, but they're constantly evolving, especially when it comes to system configuration and desktop integration. The real problems, such as they are, are much higher up the stack than packaging. systemd is trying to address that problem by inserting itself at the center of the universe, but irony of ironies, containers mean everybody is running dozens of different instances of systemd.

These container solutions don't solve anything real. They're shiny new tools for sysadmins to play with, and big fat excuses for developers to create even worse and packages.

Re:Why?

[F.Ultra]

Well each to their own I suppose, myself I have upgraded numerous servers and desktops all the way from 8.04 to 14.04LTS (and 15.10 for the desktops) without any problems what so ever. Not claiming that you didn't experience problems, just that it's not universal. I bet that you can find installs where Debian could not be upgraded without problems or any other distribution for that matter.

Re:Why?

[igloo-x]

LTS to LTS distribution upgrades (e.g,. from 12.04 to 14.04) aren't usually possible on launch day. At least with 12.04 to 14.04, you had to wait until 14.04.1, which came a couple of months after.

Though to be honest, if your operation hinges on in-place distribution upgrades on production systems, you've got bigger problems.

Snaps!

[Anonymous Coward]

Modern snap snappers know that only snaps can snap snaps, so give up on your insecure luddite packages and use snappy app snaps! Snaps!

32 Bit EFI

[johnsmithperson123]

The really sweet feature is native support for 32-bit EFI. Finally all of us who bought cheap BayTrail tablets can install Ubuntu like normal people.

Re:Winlux 4va !

[NotInHere]

Well I hope that open source packages won't switch to the new snap system, as of course it adds duplication, and now many application providers have to update one of their libraries only because of some badlock vuln or something. Some app store owners try to counter this by threatening app owners to take down their apps if they don't update the libraries. But this only gets the biggest libraries and those with most light shined on them, the small library might never get updated.

Yes, poettering has seen correctly that the duplication can be fought with fs level dedup like btrfs is doing it, but that still doesn't solve the update problem.

Where the snap system shines at is closed source applications and open source applications which both get shipped outside of the distro's packaging system: if adopted by all distros, you can ship cross-distro binaries without having to bother about some distro's settings for their libraries.

And closed source applications is one of the areas the linux desktop sucks at. There are almost no linux versions of many more or less popular closed sourced applications.

XKCD

[darkain]

Obligatory XKCD reference: https://xkcd.com/927/

'More secure'

[Junta]

More secure as in 'have to wait for app packager to update openssl library rather than updating it system wide and taking care of all dynamically linked apps'.

In fact, for 'security' I'm having a real time linking the rhetoric to a meaningful benefit. Among the benefits of this sort of strategy, I don't see how security would be one of them.

Re:Stupid appers

[Junta]

I agree, funny thing is that application packaging can *already* bundle their own version of a library, if they cared. That's part of the whole point of the /opt/ filesystem hierarchy, to give applications their own space to apply *whatever* they want

Scant on details, high on assumptions

[digitalderbs]

The details on this new packaging system are scarce--and I've checked--but it looks like a reimplementation of Docker, which would be a welcome addition. A number of comments have stated that this would lead to library fragmentation and security problems with a large number of library 'copies' needing updates. However, if this is implemented like Docker, all the apps would depend on a core image that would be updated in itself.

Frankly, docker apps are the future of package management. Each app is sandboxed (like a chroot jail), and you can establish firewall-like access to the app for directories, services and such. Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.

The only puzzling aspect of this is why ubuntu didn't just use Docker. X connections are non trivial with Docker, and perhaps this new system makes access more straightforward. In any event, I think there's more than meets the eye here. Apt rocks, but docker is better for package management.

Re:Scant on details, high on assumptions

[Etcetera]

Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.

This is 2016. What Linux distro out there still has a "dependency hell" problem? Yum and Apt-get are a decade old and handle dependency resolution. If your packages are compiled against a "core image" (or actual, bona fide release) and your repo is generated wrong and you're experiencing "dependency hell" then either:
a) someone is doing something wrong, or
b) you have an actual, bona-fide file conflict that can't be automatically resolved

wow. so edgy

[Anonymous Coward]

Yes, grampa, people still use Ubuntu. The only bad part about Ubuntu is the Unity desktop environment. Xubuntu and Ubuntu MATE don't suck.

If you make the mistake of downloading the vanilla Ubuntu ISO, all you have to do is install a better desktop environment (apt-get install xfce4 or apt-get install mate-desktop), logout, login with the new DE, and then remove unity (apt get purge unity*).

Read about it before commenting, people!

[emblemparade]

Wow, people commenting seem to have so little information about what this actually is. (Canonical is partly to blame for, as usual, doing a poor job at messaging.)

This is not replacing the Debian build system or Debian packages. Ubuntu will continue to be based on Debian.

This is an additional packaging system that makes it exceptionally easy to more reliably distribute Linux applications and services. Underneath it uses LXC (also originally developed at Canonical), the same jail-like technology that powers Docker and LXD. It basically lets the application get its own "view" of the operating system's filesystem (using AuFS) so that you can distribute required dependencies with the application. Of course it can't override the Linux kernel or other important system services, but it actually solves a major hurdle in distributing software across various OS library baselines. Until now, we've been using PPAs or other external Debian repositories to distribute software -- you can still use them if you prefer, but these are tied to the baseline and need constant tweaking to the packagers. A Snappy package made now should be able to run years from now without a problem. The Snapcraft packaging tool is very easy to use and does so much of the hard work for you: you can even just give it a git repository URL, and it will pull and build and package. I see it being very useful for something like Steam.

Also, like Docker, Snappy uses SHA-signed diffs, so package updates will be very fast. It also makes it trivial to switch between versions.

The announcement is that Ubuntu 16.04 will come with Snappy built in, so you can immediately install Snappy packages if you want. You don't have to.

There is also a new flavor of Ubuntu called "Snappy Ubuntu Core" in which the base OS itself is a Snappy image, so that it gets updates the same way as the other packages, and in the same way you can switch between versions. It is useful for various special use cases. For example, a phone OS will have an easier and safer job upgrading while letting the user trivially revert back if things break. It is not the official Ubuntu recommended for all users, but rather a building block for developers to create specialized Ubuntu-and-Snappy-based distributions.