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
   

   View Slide

2. In the beginning
   

   View Slide

3. CC-BY-SA Ruud Koot
   

   View Slide

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
   

   View Slide

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
   

   View Slide

6. CC-BY-SA Xyzzy n
   

   View Slide

7. View Slide

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!
   

   View Slide

9. Meanwhile in Linuxland
   

   View Slide

10. CC-BY-NC Dustin Jamison
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. Mission Accomplished?
    ●
    Compatibility
    ●
    Portability
    ●
    Pace of Change vs “It just works”
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. Back to the Future!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

23. Compatibility & Portability
    

    View Slide

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
    

    View Slide

25. Compatibility & Portability
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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” - ?
    

    View Slide

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!
    

    View Slide

30. “With Great Power…”
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

36. What are we going to do?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

41. What has been done?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

46. What about Flatpak?
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

51. The only people Flatpak helps today are
    distribution builders
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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?
    

    View Slide

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."”
    

    View Slide

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
    

    View Slide

57. Thank You
    

    View Slide

58. Join Us at www.opensuse.org
    

    View Slide

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/
    

    View Slide

60. View Slide

61. RUN curl -o wordpress.tar.gz
    -SL https://wordpress.org/wordpress-$WORDPRESS_VERSION}.tar.gz
    

    View Slide

62. FROM php:5.6-apache
    

    View Slide

63. View Slide

64. && make -j"$(nproc)" \
    && make install \
    

    View Slide

65. FROM debian:jessie
    

    View Slide

66. View Slide