 Hi. I'm here to talk about Flatpak. Many of the talks in the packaging dev room are like traditional packaging, like Debian packages or RPMs or whatever. This is not that. But hopefully you don't all see it as the enemy. So Flatpak is a sandbox app framework for desktop Linux. The one line pitch for it is what if we could have Android apps but with more open source and better. It started life as XDG app, which is a horribly unwieldy name, so it's a good thing that got changed. It's mostly maintained by Alexander Larson at Red Hat, but it's very much a community effort. There's ongoing contributions from Endless, who are big fans of it, Collabora, who I work for, Red Hat, Nome, Debian, Arch Linux. It seems to be picking up for momentum and you don't need to sign a CLA or anything like that to join in. So contributions from everyone, welcome. And yes, the name is a reference to IKEA. Hopefully your packages won't all be wobbly and fall over. So Flatpak is for applications, which is very vague loaded term. But as a first approximation, it's about the stuff you get in user share applications like things with a desktop file, things you see in your menu, things you can launch as a user facing app. Also applications as in App Store. On desktop Linux, we don't really have an equivalent of Google Play or the Mac App Store or things like that. And Flatpak is providing the infrastructure that we would need if we want to have one. So things that are not an application, Flatpak will not do. It's very much not for platform services and infrastructure. So things that are like a key part of your desktop, like Deconf and Divust Demon and services like that, not suitable for those. Your desktop shell itself, like Nome Shell or KDE Plasma or that kind of thing. Flatpak is not for that. It doesn't try to be. Sort of low level utilities like X terms, none of that. Also it's not really intended for command line tools. So having a Flatpak for Python probably doesn't make sense. And definitely not for system services. We don't want Apache.Flatpak that's just nonsense. Another of the key things is Sandboxed. So you trust the app a bit. You've chosen to install it. You'll let it get to some of your data. And obviously this requires you to trust it to get at the attack surface of your kernel, which with Meltdown and Spectre floating around is a bit of a big thing to ask. But even so, you shouldn't have to, just because you've installed like LibreOffice, it shouldn't be able to read your .gnpg or your bank details or stuff like that. It should be able to read the data you've given it and no more. And it shouldn't be able to record you talking unless it's an app where that makes sense. And it's for desktop Linux. So we're taking full advantage of Linux namespace features, cgroups, user namespace, that kind of thing. So all the same building blocks as more server-oriented container technologies, but used in a different way. No attempt to be portable away from Linux. You know, pick your backings, writing portable software is really hard, particularly if you want it to do clever things. It is not specific to a particular desktop environment. You need some sort of a desktop environment, obviously. It's primarily targeting Nome and KDE, but it doesn't have to be. You can run it in whatever. It doesn't require you to have a specific LSM. So, like, you can use it on a system that has SE Linux like Red Hat or on a system that has APARMA like Ubuntu or recently Debian. But you don't have to. And it doesn't need system D for all those who carry out CSV in it. Although, if you're running system D, it will put your app in a C group. So it helps a bit. So, rather than having a tree of dependencies, Flapac tries to give your app a stable platform to sit on with these things called runtimes. So the problem here is, this horrible term ISVs, third party software vendors, they can target Windows, they can make an app for Windows, they can make an app for Android or for Mac OS. But they can't make an app for desktop Linux because the Debian people have one version of libJPEG, the Fedora people have another version. Some people have libJPEG turbo, some don't. Which of the many branches of things like SDL, GTK, QT do you have? Even if you're assuming a GTK 3, there are subtle behaviour changes between some branches, so you kind of need to know which one of those you're on. And if your app has anything to do with the desktop environment, like interacts with it directly, then there's a bwildering variety of desktop environments and build your own desktop environment that it could be running on. And app authors kind of shouldn't have to care about this stuff, they should just be able to go right, here's my app, and the system it's being run on will provide a suitable environment for it in the same way that Android has API compatibility levels, so you can have an app that's built for compatibility level 17 and it will get a predictable environment. So the traditional solution for this has been for ISVs to pick some distribution from the distant past, traditionally Red Hat for some reason, and build all their software on an ancient version of that. And then hopefully because everything is backwards compatible, right? Hopefully that will work on actually modern platforms as well. So the LSB is a vendor neutral baseline for Linux. And provides everything you need to run your app if your app is 10 years old and doesn't do very much. So that's not particularly useful, it's quite telling that for instance, Steam games have totally ignored the LSB. It just doesn't have enough stuff in to be useful to them. So more recently people have picked up on Ubuntu as their reference platform for this is what we did our QA on, you couldn't use it on other stuff, good luck. So Steam for example, major app distribution platform obviously. Its games run in an Ubuntu 12 environment. This is from 2012, it hit end of line for mainstream security support last year. It's not a great platform to be basing your world on. Basing on an ancient baseline like this guarantees that all your LSBs have the platform problem. When they have a feature they need or a bug they want fixed or whatever, there's no incentive for them to actually go and do the work and fix it and contribute back to us. Because they're going to be running on Ubuntu from five years ago anyway so they're not going to pick up the bug fix anyway. So why would they bother? Which is kind of a problem because you know we're a community, we need everyone's help. So the other solution that ISVs have traditionally done is bundle everything into a giant monolithic package. Or more commonly kind of hybrid of the two. So you choose your baseline version, you have like Red Hat 5 or something. Whatever is in that, if it's new enough in that fine will depend on it. And if it's not in that or if it's if we need a newer version bundle a copy. So people try and do this by static linking which is great up to a point except when you link Gilib C and suddenly it's opening NSS plugins that depend on libraries anyway and now you're loading libraries you didn't QA with despite your best efforts. Or slightly more advanced you link your application with an R-path which affects how it searches for its shared libraries. So redirect it to look instead of looking and use a lip have it look in this directory here and it picks up the version you QA'd with instead of the version the distro came with. Or you can use LDL library path at runtime to have essentially the same effect. And again this is fine up to a point but you get like bits of the base system leaking through and accidentally end up using a library from the base system where you wanted your bundle library and then your app doesn't work. It's also of course a problem because you've bundled an ancient version of maybe lip soup or lip curl or something network facing like that. And unmaintained code from five years ago on today's internet is not the finest of plans. So Flightpack has platform runtimes. These are what your ISV app runs on. It's essentially a copy of slash user from a suitable library set. So the idea is you have a runtime that is something like the GNOME environment with a fairly complete set of GNOME libraries and like 90% of your dependencies come from that. And you just use those. They're maintained by the maintainer of the runtime not by the maintainer of the app. And if there's specialised stuff you need. So for instance you have dependencies that are you need a very new version because you're closely tracking it or it's a really obscure library. It's not in the GNOME platform or whatever platform you're running on. Then you bundle it and by doing that you take responsibility for dealing with that. And the host system slash user is usually just not visible at all to the Flightpack app. So if you're using a Debian 9 runtime and you're running your app on Fedora 27 it doesn't see Fedora 27 libraries. It sees the libraries it was tested QA against. So hopefully it actually works. I mentioned a Debian as a possible runtime. Anyone can publish runtimes. There's no central blessed Flightpack runtime that everyone must use like there is with Android. So the runtime maintainer chooses what they're going to put in it. If you want the complete GNOME library stacking your runtime, fine, have that. If you want a very small runtime with like libc and libjpeg and nothing else you can do that. And it's up to you as a runtime maintainer how closely you track the latest versions. You don't need to include development tools. I'll come to that. You don't need to include system administration stuff because this is not a complete operating system. It's just a library stack. You don't need a package manager because you don't upgrade the runtime by like charooting into it and running app get. You update it by replacing it. There's some optimization obviously but the principle is throw it away, get a new one. And you don't need like any system or any system demons like that because again it's just a library stack. It's never going to boot. And conventionally these are something.platform like there is org.nome.platform which is a reasonably complete GNOME stack. So for the development tools you have SDK runtimes. These are what you use to build your app also what you use to test your app if you want some debug tools. So the SDK includes everything from the corresponding platform. It also includes like the header files and static libraries you need to build against it. It includes the C compiler you're using to link the thing so you can make sure you're getting the C++ ABI you think you are. You can include debug tools in it and people do because it's really useful. And conventionally if your platform runtime was whatever.platform then there's a corresponding SDK. Obviously just having like the GNOME runtime doesn't make a whole lot of sense because if you want a stable platform that's the opposite of let's use the latest GNOME. So you can branch runtimes by setting like a major version for them and the runtime maintainer chooses what they're going to track. So for instance if you are so that there's a thing called the free desktop platform which is a bunch of low-ish level libraries mostly from free desktop.org but also like lower level things like libjpeg. And that just has an arbitrary version number because there's no good version number for that right. It's a collection of libraries from everywhere so it's maintainer just gives it an incrementing version. The GNOME platform is versioned by the version of GNOME it came from and that's like the major version so if you have like security fixes and other minor bug fixes stuff you'll stay within the same branch and just pull those in gradually. But anything that might break your app like the jump from GNOME 326 to 328 or whatever you would have a different branch from your runtime. And the app maintainer can choose which version they're going to target and update at their own pace within reason. Or if you are Fedora and you're making runtimes which they do you might version it with like the major version of your distribution or I've been doing some experimenting with runtimes based on Debian and again I'm using the distro version. So you get stable point releases you get security updates you don't get breaking changes. As I said it's important that you actually get your security updates if your runtime maintainer isn't updating stuff you won't get updates sorry. And there's like a division of responsibilities here whatever you put in the app the app author is responsible so if your app author is good they'll update their bundled libraries if they're not you already have problems with the code they wrote. So I'll go into a bit about how the runtimes work. Flatpak uses a library called libustry which is essentially get for the contents of slash user it's originally designed for deploying whole operating systems but it works fine for a runtime as well. So you have your configuration you have your branches you have your content address storage wait a minute that's just get. This is actually Austria as you can see it's essentially the same you have your branches you have your hashed storage that the hash is the hash is a longer because show on is not looking as good as it used to but it's all the same concept. And because it has content address storage it automatically duplicates so if you have two runtimes and they have exactly the same build of lib C. And you have an app that depends on one you have an app that depends on the other you only have one lip see it just hard links stuff together that's identical. So hopefully a lot of your runtimes are quite similar and can share most stuff. Obviously as soon as you start writing to these files that breaks horribly so the runtimes are deployed read only so the app just cannot change them. And I said you update them by pulling in a new copy so using the duplication for things that haven't changed to stay the same. And you you like swap a sim link and you throw away the old copy because you don't need it anymore. It uses Linux container technologies to set the app up. So the app appears on app the runtime appears on user. And it exposes bits of the host system as needed. So like you get ETC hostname you get resolve.conf so you can actually do DNS. And if the app needs them you can get things like the hosts debuff sockets or pulse audio or selected bits but not the whole system. This is all done with a tool called bubble wrap which restructuring the mount namespace is obviously kind of scary. You need privileges in a user namespace and in a lot of distros you can't go into a user namespace without having capsis admin. So the point the idea of bubble wrap which used to be xdg app help a part of flatpacking a spawn off a separate project. It's the minimal bit that needs to be set you in route on some systems so that all of flatpack doesn't need to be. So in some systems similar to flatpack like fire jail I think the bit that has the like business logic for how your app works is the same bit that set you in route. Which means you have a lot of code potentially running as route and that's kind of worrying. So by using bubble wrap flatpack avoid stat. Obviously some apps need more access than others a lot of apps need to talk to x11 so there's permission system a bit like Android. You can give your app access to areas of file system or to other capabilities or you can deny them and the user can override these before or after installing the app. This is not perfect obviously if you have given an app access to x11 you can't very well just take it away halfway through that would work. So in this model either you have the capability all the time or you have it never and obviously sandboxing is really hard and this is very much work in progress. It's already useful it's still improving. One of my current projects is integrating some code into diva steam and to make it better at sharing stuff with sandbox apps without sharing literally everything. The other permissions mechanism is this thing called portals where the app gets like constrained access to stuff outside the sandbox. So obviously asking the user for permission is quite good if you phrase the question suitably. So not like a browser as a hell but the prompts in a browser for like do you want to let this VoIP web app use your microphone make a lot more sense. Well yes I do obviously I want to be able to talk to people. So the document portal is like the flagship example of these. The app uses for instance the ordinary GTK APIs or QT APIs or whatever to open up a file open or file save dialogue. And the bus magic happens and the dialogue appears outside the sandbox in a different process entirely with different privileges. And it sets some hints on the window for that so that the compositor if it has support for this which for instance Nome Shell does will like visually glue together the dialogue and the app just as though it was in process. So your file open dialogue can see all your files even though the app can't. And if you cancel the app doesn't get anything it just gets the user cancelled. If you choose a file the portals infrastructure goes and finds that file makes it appear in a fused file system which the app can see and tells the app hey I've put it here. And so your app can get it exactly the file you chose. It can't get at your other files and as a user you don't necessarily even realize you're being asked permission it's just the obvious right thing happens. So that's quite good. There are various other portals from the XDG desktop portal project which do mostly work over debuts and do things like letting your app start composing an email. Or open a URL or various things like that. And these all as much as possible the request for permissions is fairly implicit. It's like it lets the app start composing an email but it doesn't let it send an email so it's always the user's choice to actually send the thing. Or where that's not possible it will pop up a thing saying do you want to let this app take a screenshot for example. And if you say yes it gets your screenshot if you say no it doesn't and you can tell it to remember that decision. So in the common case like on Android you will usually only get asked once. So very very briefly how to build flat packs. The normal way to do it is you build the flat pack app in an SDK runtime so you choose which platform you will target to be one that you can do your QA process on. There is a tool called Flat Pack Builder which you give it a JSON manifest listing the libraries to bundle and like how to run your configure script. You configure for the prefix slash app and you don't need to alter your apps code to make it relocatable. So you don't need to change your code to respect various environment variables and that kind of thing. You can just assume it will be in slash app so apps that hard code paths are fine. Or alternatively if you need to build one the hard way a lot of apps are actually relocatable. So if you have some random binaries you can just make an OS tree with the right paths in it and commit it. And I don't think it's coincidence that slash user is the same length as slash app. So if you absolutely need to get your hex editor out I wouldn't recommend it but it's valid. If you'd like a bit more detail on how Flat Pack interacts with traditional Linux distributions I will be giving another talk here tomorrow. Any questions? How about Wayland? How about Wayland? Yes. So if you are using Wayland your apps will get access to the Wayland socket. You can take away the X11 privilege if you know that they support Wayland and they will not be able to do evil things like run a key logger. Second question. How about Eclipse? It's an IDE. Is it in theory? Good luck. In principle sure yes. In practice because it doesn't use like for instance standard GTK things you will probably need quite either code changes or giving it a lot of permissions. But yeah sure. If you can run the app you should be able to Flat Packify it somehow. I'm sorry I don't think I have time for any more questions. One more, okay. You were there first. Actually, since I've got a lot to ask my question was is it alright if I get in touch with you outside of... Sure, of course. E-mail address or if you've got any... Yeah, espacavayet.com. It's on the first slide and the slides are online already.