GUADEC 2017 - Flatpak - Future, or Resurrected Dinosaur?

Containerised Application technologies like AppImage, Snappy and Flatpak promise a brave new world for Linux applications, free from the worries of shared libraries and dependency issues. Just one problem, this is a road long travelled before, such as in the application dark ages of Win32 applications and DLLs. And it worked out so wonderfully there… Do we risk a future where, like the resurrected dinosaurs of Jurassic Park, this family of applications will break their containment and start eating our users? This session will try to present a balanced argument about the situation, frankly discussing the benefits promised by these technologies, but highlighting the very real issues and risks their widespread adoption could, and in some cases are, already bringing to the table.

The talk with cover the promised benefits of application containers, such as AppImage, Snappy and Flatpak. It will detail the empowerment of developers who use the technologies, the ability for upstream projects to have a much closer role in delivering their software, and the benefits that brings to both the upstream projects and their users. But as a counter to those benefits, the session will detail some of the risks and responsibilities that come with that technology. The complexities of library integration, the risk of introducing new forms of dependency issues, and the transference of responsibility for those issues, plus security, away from the current Distributions delivering upstream projects towards those upstream projects directly. As a conclusion, the session will present some suggestions to upstream projects adopting these technologies to start them down the road of accepting those responsibilities directly, or working more closely with existing Distribution projects to share the burdens these technologies now provide.

Transcript

1. Richard Brown openSUSE Chairman rbrown@opensuse.org Welcome to Jurassic Park We been preoccupied with whether we could or not, lets stop and think if we should
2. In the beginning
3. CC-BY-SA Ruud Koot
4. DLL Hell • Developers had to dev & test Apps on every possible DLL combination • Then retest every App patch on every possible DLL combination • AND test every DLL patch on every possible App & DLL combination • Then cry when it all broke anyway
5. Windows 2000 to the Rescue • Side-by-side (SxS) assembly – DLL “Containerisation” – Separate Memory Space for each App and its DLLs – ‘Private DLLs’ loaded from the Application Directory • Windows File Protection (WFP) – Disk Isolation of System DLLs • DLL Universal Problem Solver (DUPS) – Audit all the DLLs in use and help migrate ‘legacy’ applications to SxS bundles
6. CC-BY-SA Xyzzy n
8. Problem Solved? Right? • Security nightmare – Security relevant DLLs lurking in countless application folders • Maintenance nightmare – How are we going to update our app? Oh we’ll ship an updater! • Legal nightmare – Can we legally redistribute all the DLLs we need to? • Storage vendor dream – More disk consumption, everyone buying bigger disks!
9. Meanwhile in Linuxland
10. CC-BY-NC Dustin Jamison
11. Distributions – Solving Real Problems • Security – Security Teams auditing packages, monitoring CVEs & embargoed lists • Maintenance – Maintainers packaging applications & keeping them updated • Legal – Lawyers auditing licenses and ensuring compatibility/compliance
12. In Defence of Shared Libraries/Dependencies • Not just about using less space on disk • Distributing fewer libraries have broad benefits – Fewer INSECURE libraries, more easily patched – Less manpower required to maintain/update – Easier to review/ensure legal compliance
13. Mission Accomplished? • Compatibility • Portability • Pace of Change vs “It just works”
14. Compatibility • Many distributions with many diferent libraries and apps • Diferent apps require diferent libraries • Application developers don’t want to worry about what other application developers have chosen as their dependencies
15. Compatibility • Many distributions with many diferent libraries and apps • Diferent apps require diferent libraries • Application developers don’t want to worry about what other application developers have chosen as their dependencies • But application developers don’t (ofen) worry about this • Distro Maintainers work on this for F/OSS licensed apps
16. Portability • Many distributions with many diferent libraries and toolsets • Application Developers don’t want to learn dozens of toolsets, nor rebuild & retest their application on a dozen platforms
17. Portability • Many distributions with many diferent libraries and toolsets • Application Developers don’t want to learn dozens of toolsets, nor rebuild & retest their application on a dozen platforms • But application developers don’t (ofen) worry about this • Distro Maintainers solve the problem for F/OSS licensed apps
18. Pace of Change vs “It just works” • Many distributions with fixed release schedules • Distributions freeze package/library versions to aid ‘stability’ • Holds back new application versions from users
19. Pace of Change vs “It just works” • Many distributions with fixed release schedules • Distributions freeze package/library versions to aid ‘stability’ • Holds back new application versions from users • But application developers don’t need to worry about this • Rolling Distributions resolve this with increasing eficiency
20. Back to the Future!
21. Containerised Applications to the Rescue • AppImage, FlatPak, Snappy • Provides uses with a “Bundle” containing App + Libraries • Runs the App in some kind of Sandbox or Container
22. The Big Promises • Compatibility – SOLVED – Only compatible libraries in the bundle • Portability – SOLVED – All dependencies in the bundle • Pace of Change – SOLVED – App developers can distribute at their pace, not a distro pace • “It just works” - SOLVED
23. Compatibility & Portability
24. Compatibility & Portability • Containerised Apps at some point make assumptions of a common standard base provided by the Distribution • No such common base exists in a practical sense
25. Compatibility & Portability
26. Compatibility & Portability • For a Containerised App to be portable, it must contain ALL compatible dependencies which MIGHT not be provided by ANY distribution • If not, expect crashes
27. So it’s hopeless? If everything is still liable to break, what is the point? • Frameworks/Runtimes attempt to mitigate by providing curated ‘Middledistros’ to build Applications for • The “Real” Solution: A well defined Linux Standard Base?
28. The Big Promises - Reality • Compatibility – SOLVED – Only compatible libraries in the bundle • Portability – SOLVED – All dependencies in the bundle • Pace of Change – SOLVED – App developers can distribute at their pace, not a distro pace • “It just works” - ?
29. History Repeating? • Security nightmare? – Security relevant libs lurking in countless application bundles • Maintenance nightmare? – How are we going to update our app and every single lib? • Legal nightmare? – Can we legally redistribute all the libs we need to? • Storage vendor dream – More disk consumption, everyone buying bigger disks!
30. “With Great Power…”
31. “… Comes Great Responsibilities” • AppImage/FlatPak/Snappy are tools that enable App Developers to directly distribute sofware without the ‘need’ for Distributions • Therefore, they must adopt the responsibilities which come with being a distributor of sofware
32. Compatibility & Portability Consider everything an App needs that isn’t in the Bundle • Can this break my App if the ABI changes? – If YES, then move it to the Bundle • Can I rely on it being there on ALL systems? – If NO, then move it to the Bundle
33. Compatibility & Portability in Real Terms Application Developers will still need to • Dev & test Apps on every possible distro • Then retest every App patch on every possible distro • Then cry when it all breaks anyway
34. Compatibility & Portability in Flatpak Application Developers will still need to • Keep up with their chosen runtime releases • Dev & test Apps on every possible distro • Then retest every App patch on every possible distro • Then cry when it all breaks anyway
35. Broader Responsibilities • Security – Monitor & rapidly react to CVEs. Audit libraries. Do not assume sandboxing is enough. • Maintenance – Update all bundled dependencies in a timely manner • Legal – Review licences of all bundled dependencies and ensure compliance & compatibility
36. What are we going to do?
37. Distributions can be part of the solution • Distributions should like the promise of Containerised Applications • Less work & responsibility for us is always good • Should not be fearful of the transfer of responsibility, but should not encourage it blindly either
38. Distributions can be part of the solution • A Common Base (“LSB for the Container Age”) must be considered – Without one, the portability promise is unachievable • Distributions have decades of tools and talent for dealing with the broader issues. USE THEM • Don’t reinvent every wheel just because we can
39. Change ALL THE THINGS • Is the assumption that distros ‘get in the way’ of App Delivery still valid? – Transactional Distros (Project Atomic, SUSE CaaSP, openSUSE Kubic) – Rolling Releases (Arch, openSUSE Tumbleweed)
40. Rolling Releases for Everyone? • To get Applications in the hands of users fast, what model beats a rolling distribution? • Users can be guaranteed an integrated “built together” experience • Security/Maintenance burdens less broadly distributed, fewer points of failure, Devs don’t need to be security engineers • “It just works” can be reached with good tools – OBS & openQA
41. What has been done?
42. AppImage race ahead • OBS built AppImages make use of OBS & openSUSE’s strengths in – Auditing – Update & Dependency Tracking – License Compliance – Build Hosting • All without impeding AppImages strengths in getting the sofware in the hands of users
43. Snappy catching up • Adopting “Upstream First” mentality • Canonical provided/maintained ‘base snaps’ • Concerted efort to work with distributions & other upstreams to build an ecosystem • Yes, Canonical are trying to work with others
44. Problems Remain • Dependency Hell still on the Horizon – Assumptions are still being made about what a base system must provide containerised apps – Let’s all get together, distros & new app formats, and discuss & design standards/common practice – A common understanding of what distros provide will make life easier for App developers, users, and distributions
45. Problems Remain • Security / Sandboxing / App Isolation is still a mess – Snap requires not-yet-upstreamed AppArmor patches – Flatpak – bubblewrap, too desktop orientated? – AppImage – firejail/nothing • Let’s clear this up – AppArmor all the way?
46. What about Flatpak?
47. Dear Flatpak • I fear Flatpak is falling behind • AppImage has a smoother build story, a stronger compliance story, and a more straight forward user experience • Snappy is working hard to catch up, by working with multiple distributions • openSUSE / OBS / openQA and more are all here to help
48. Who does flatpak help? • App Developers? – Still needs to worry about dependencies (runtimes & distros) – New/complex not-rpm & not-deb packaging – Can be invasive to add Flatpak support to an App – What if I don’t like Builder?
49. Who does flatpak help? • Upstream Stack Developers? (GNOME, KDE, etc) – Now has to worry a lot more about integration (runtimes are their problem) – Now has to worry more about maintenance, security, legal – Now has to worry more about UX
50. Who does flatpak help? • Users? – New/complex not-rpm & not-deb tooling. – Flathubs? Appstores? – New versions quickly without quality controls will equal getting new bugs quickly
51. The only people Flatpak helps today are distribution builders
52. Flatpak – technical concerns • Portals & Exports – Scary holes punching through many stacks (MIME types, search, URIs, etc) – How to audit? How to keep secure? Who enforces sane behaviour? – #1 Issue holding back openSUSE’s adoption of flatpak • No ‘headless app’ story
53. Flatpak – ecosystem worries • “We do High Quality Engineering” • “We care about the stack” • “We take responsibility for the users experience” • GNOME does – what about others? – A lot of responsibility on runtime maintainers – Security, timely maintenance, legal • Flathub – a chance to impose principles?
54. Flatpak/Flathub – a much larger legal problem? • Who is the distributor? Who takes the legal responsibility? – Freedesktop.org? (FDO runtime, flathub) • License Audit – Who’s doing it? – Who should be doing it?
55. NVIDIA License “2.1.1 Rights. Customer may install and use one copy of the SOFTWARE on a single computer, and except for making one back-up copy of the Sofware, may not otherwise copy the SOFTWARE. This LICENSE of SOFTWARE may not be shared or used concurrently on diferent computers."”
56. Final Thoughts • To avoid another deb vs rpm split, only 1 containerised app format should survive • My heart wants Flatpak • But we need to address issues • Distros solved many of them already • Lets work together
57. Thank You
58. Join Us at www.opensuse.org
59. License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/
61. RUN curl -o wordpress.tar.gz -SL https://wordpress.org/wordpress-$WORDPRESS_VERSION}.tar.gz
62. FROM php:5.6-apache
64. && make -j"$(nproc)" \ && make install \
65. FROM debian:jessie