 So that's not my turf exactly how to operate this office suite. But if you come with a question like trying to build that with my latest GCC6 version and there's a 10 line error message, that's a question that I would like to discuss with you. But what we'll actually talk about today is seeing to get LibreOffice integrated or working with the XCG app thing, which is a kind of two-thing approach. So what actually is XCG app is, I think, even a Wikipedia site for it now. So it starts to get popular. It's an approach to this common set of problems that you have programs on the internet, programs from anywhere. You want to make sure that they do run on your computer on the specific set of libraries and APIs that you have on your machine that might not be the ones that the person who actually built that software has. You also want to have security if you download some program from somewhere. You might not be too sure that that is something that wouldn't do something malicious to your machine. So the idea for the Linux ecosystem is XDG app, which started off in kind of the GNOME, Fedora, Redhead world. And yeah, there's these two ideas behind it. Have some format to ship software to the end user in a way that it will definitely run there and make it run there in a way that ideally it can't do any harm if it turns out to be more from a guy you would want to trust. So the other part of the puzzle is LibreOffice in this case. It is huge. It has nobody exactly knows how to count the number of the lines of code, for example, because it's so many months, but it's in the millions. It has a very long history through time, through various incarnations of StarOffice, OpenOffice. Now we're at LibreOffice. It dates back to the 1980s, even the oldest parts of the code. It runs on all different platforms or all the ones that are still relevant today. We dumped the OS2 port at some point, but we're still Linux, Microsoft, of course, Mac. Building that is often kind of a challenge because we come with, like, in the hundreds of configure switches, you can enable, disable kind of anything from whether you want to build a debug build through the help content and the UI and what kinds of languages you want to bring that along. And all the libraries that typically on Linux you find on the system. But on Windows, for example, they are not there, so we need to bring along these, at least for Windows anyway. So we have a zoo of, like, 100 sub-modules that are integrated in our code. So we don't ship the actual code of those. You need to get them from the internet as well as Tables. We automate that. But then we integrate that into our build system so that we have just one make, everything that then goes into all these sub-modules so that you did want to include and build that as well. So typically, typical sub-modules are built-only-boost thing, for example. But we also ship our own complete Python 3 because some platforms just don't have it. And then more of a specific stuff like this zoo of little libraries that help us in importing the various file systems, document file formats that are out there. So we have split that out as well. Another part is that, as I said, you can specify which languages. And we have localizations in around 100 languages by now. There's a quite vibrant community around LibreOffice translating it into all these various languages. And there's ever more coming and trying to pick that up. So yeah, that's what LibreOffice is. And we're quite prominent for whatever toolchain there is out there. We sure to break it at least in one or two places. So that's also my main point of interest in this big office suite is not the applications that you actually run. But this large corpus of software that when you think about some compiler improvement, for example, that will be cool to try out or implement it in Clang as a plug-in, then you're sure if you run it on that 1,000,000 code base, you'll at least find one or two places where that your check actually hits and you can find a unit there and be happy that you improved our code base with a dent. That's great. So a natural fit for a new environment to run applications in like XGJAP is to try one of the big ones. And if that one sticks in there and works in there, then we can be pretty sure that XGJAP is a technology that works also for the humble little, all the other apps that are out there. So what do we do? I'll first start with a part about actually building LibreOffice so that it fits into XGJAP. That's the one part of XGJAP so that we can distribute it. The other part, of course, is the sandboxing, seeing that it doesn't do any harm. And I'll come to that in the second part. So as a set, we have a multi-platform. So the easiest platform to target actually is Mac because that's a very tightly controlled one. You exactly know what's available if you target Mac 10.8, for example, as your minimum baseline. Then you're sure what to find there. Windows as well. But unfortunately, Linux is more fractured because of the more free approaches we have here. So that's a pro and can be a con as well if you actually try to build your software and distribute it there, like the different package formats, different versions of libraries. So what that leads to is that every Linux distro actually builds and packages and distributes LibreOffice to themselves. Problem solved not completely because some distros might be outdated. We have a very active development cycle. So every half year, we deliver a new version, a minor version. So 5.1 is around the corner. Next week, I think, we'll happily put that out. So people want to use the latest and greatest always. And QA people want to test that stuff. So we need to have builds available from our LibreOffice itself. So when switching hats from my Red Hat hat to my document foundation, that's the legal entity kind of thing behind our LibreOffice upstream. And we need to see how to build that stuff and get it out to Linux users. So what we do at the moment is to have some old Santos baseline that we settle on, but that, of course, is drawbacks. Because when it's an old baseline, you don't have the new features you only could use GTK3, for example, since recently, and other problems. And some people use KDE. So there's also problems if you use some known specific functionality, like the spec ends to talk to all these various internet protocols to download documents from, then there's no alternative in KDE, for example. So we need something better there. And our hope, of course, is that the XCG app will gather enough traction that it is the new format in which we can deliver this to all happy Linux users. And another benefit, of course, will be that for Distro, you can stay on a stable baseline there on a stable fundament. Don't need to update Nome on your complete Distro, just to benefit from Nome updates that you would have in LibreOffice. So could also be a cool feature for Distros like REL. Another use case where it might be definitely be interesting is there's a LibreOffice developer who had that cool idea. You want to find out something broke with one of the latest builds, something you can't see in the UI, which doesn't work anymore. So what you do is you get bisect that. When you want to do that with LibreOffice, the problem is building LibreOffice can easily take hours. So your bisecting experience will be very poor and you'll need tons of coffee for the in-between times. And you can't easily tell one of our eager QA people who would like to bisect that down, but you can't tell them, yeah, see for yourself how to build that and see which build actually broke it. So the idea, do a Git repo for bisecting, but we don't put the code in there but the pre-built binaries. So you do a, for every version of the source, you do a build, you put it in a Git repo. I want this grow, but not that much because many of the libraries will stay the same from build to build. So we have now huge Git repos full of versions from the 5.0 to the 5.1 time period of LibreOffice. And the QA people just once download this huge blob and then Git bisecting is a snap because actually switching, checking out the actual state is very, very fast with Git. So that's cool, but the people or the person who invented that and then that was a cold winter. So we started up as Fat Machine and actually did all these builds because you once need to do these builds and he had a warm house for a while doing that. But when you do a mistake there and do it not on our Sanders baseline, but for example, our stupid and do it on a Ubuntu thing, then what will fall out of it is binaries that do work mostly, but there might be one library on Ubuntu that we depend on that has a different version than on Fedora. So many of the people who want to run these can't actually use them. That mistake did happen. The actual fix happily was to only do some sim linking of just the name was wrong for that system library so we could work around it with a sim link. But that guy didn't want to go back and reheat his house again because by now it was springtime. So if he would start it out with XG app in the first place that problem would never have happened. So this is another use case where building to a well-defined platform that is guaranteed to run on everybody's machine is definitely a win. By the way, if there's any questions, you can just ask now or wait until later. So the builder actually building the office for XG app is still quite in the kind of experimental stage so there's no official repo of it yet. But I do manage to get it built, for example, the latest the office version. What you do to get that build is the idea of XG app is that you have some specified runtime, like there's, for example, a GNOME 3.16 or a GNOME 3.18 runtime that has a defined set of functionality of libraries. Then there's the kind of SDK complimenting that that you also have the devil headers also available, which you don't need at runtime, of course, but for actually building that. It is based on some project that is a bit different from what you know from the next distro. So there is some minor places where it didn't quite fit to just download the LibreOffice Git repo and do a configure in and make. For example, we're using some obscure code still in our millions of lines to bundle stuff up. That is from, I don't know, 20 years old stuff that nobody ever bothered to clean up or rewrite in Python or whatnot. And that uses some code that's just not there in that thing. We had some glue headers. We got rid of them. So that's a benefit anyway that we cleaned out some stuff that we turned out didn't really need. So there was, for example, no glue devil packages in that XG app SDK. There was one stupid or curious hack in there when you run the XML config, which is like the package config for LibxML. Then in that Yachto thing, it was hard coded as doing an exit one. So I wondered why our internal copy of LibxML refused to work when to compile until I dug deep enough into that to find it out. I disabled some of our zoo of stuff that didn't quite work, like there's some minor issues with trying to get GStreamer. We have a GStreamer backend. We have a GStreamer 1.0 and a GStreamer 0.10 backends in there. So the 1.0, there was some glitches that just, for the first experiments, I just left it out and have to revisit how we get that working. Left out our whole Java. So the option would be to include a JVM in our bundle as well to get our Java parts running, if you want to use that at all. But what fell out there already is quite big with 300 max. So we're definitely one of the bigger bundles that will be available for XG app. The idea is that, of course, smaller apps will be just tiny in comparison to that in what you need to download. That's the price for our heavy thing. So for coming to the second part, I guess I'll give a quick demo of what we have. Can we read that? So I prepared something and called it LibreOffice. So the idea is that every application in XG app has an identifier that reversed DNS name style. So I built that package that up, downloaded it from my computer to my computer, installed it in the local XG app cache to have it available there. And then you run it that way. It no longer works, Libre. Did I mistype that? Or what is it? Not low, orc. So the error messages from XG app are still a bit... There's room for improvement there. So that just wasn't a low LibreOffice, but just an orc LibreOffice, of course. So boots up in no time. Looks like your average or normal LibreOffice experience. So there's a rider here. And you can just type in something. There's a help should even work. That's the other one. Help should even work. Help won't work. Demo time. Doesn't matter. But we want to open some document to edit it. Where are my documents? Well, they're not here. My computer, what happened? My home directory is completely empty. Yeah, that's because the thing I built here also uses the second part of the talk, the sandboxing, that this instance of LibreOffice looks like a normal one, but doesn't have any access to anything on your machine. So it has a fake file system. The app itself is installed in some app tree. So we have LibreOffice here. We do have some license file that is part of LibreOffice. We can open that. That works. But there's nothing else we can reach on the machine. So that's the sandboxing part for something like an office suite where you want to operate on your files, on your documents, modify your documents. Yeah, that's not ideal. So we can opt out of that with telling XDG app to give access to the whole file system. So there we are. We can now open a file from my home directory. And there's, for example, the very presentation I'm doing now. And that works. But there's another, even cooler way. So we stop that again. So I now opt it out of having the file system hidden. I'll opt in again to have the file system hidden. That's the original one. I'll start again. There's nothing here. But we have multiple file open dialogues in LibreOffice because we have everything. There is a way to switch that. I'll use the internal one. And I hacked that one. And what I do there is use some tunnel that is provided by XDG app via Debus to get out of the jail which LibreOffice runs in to the whole system. And I have some kind of file chooser where I get access to the complete file system to select a file but nothing more. So I can go to my slides here, select them, open them. What happens there is that I don't get access from inside the jail to the outside. I just get access to that file chooser that picks that file for me and then tunnels it back in. Just that one file, nothing more. And it's even read only here. I'll come back to that in a second. So that's the idea of how to get access to your functionality you want to have inside your XDG app jail via these portals that connect you with the outside way world in a secure way. So back to the presentation. The real one. Yes? Yeah, that's coming in a second. So that's basically what I said. With that opt-in or out, you can have that for the file system and for other things as well for talking through sockets and stuff like that. There's a fine-grained way of telling XDG app which parts of the outer world or of the system you want to get make available to the app. And for that access to the file system, how it works or the underlying idea always with these portals is that there needs to be some code that actually does not run within the jail. So we can be sure that the app in the jail cannot modify it or temper it or do any bad thing about that. It doesn't have any control about it. It just has some connection to there to ask, I want to open a file, display to the user, a file chooser. And because of that display to the user in there, it is clear to the user that that app cannot sneakily try to read your password file because the users actually ask what file do you want to open by the code that does not run in the jail. So there's no way for the jail to try to do sneaky things there because it's always code runs outside the jail. The important code has to ask the user to do something. There needs to be a trigger that the user does. So the user can be sure that he initiated the operations that operate on potentially dangerous parts. So that's the trick behind it. Same would go with printing. You would naturally open a print dialogue. Anyway, in that print dialogue, again, would not be the LibreOffice one inside of LibreOffice, but some portal-provided print dialogue. And for an app like LibreOffice, where people, of course, do trust us that we do not write code that is malicious. So this part of being afraid that this app that you download from the internet might do harm to your machine is not the most important part, maybe, for LibreOffice. But another big benefit, of course, is we're not perfect. We do have bugs. There are documents that when you open them, they might trigger a bug that does a bad thing and rewrites your hard disk. But when you run this inside of a jail, you can be pretty sure that whatever a bug in whatever obscure import filter that we have cannot cause a zero day for you. So that's the big benefit with an application like LibreOffice that consumes documents from the outside and can trigger problems in those. And then there's some special things about LibreOffice that make it not so easy to get into a sandboxed jail. Like we saw this when I got my presentation into the jailed LibreOffice and displayed it there. It was displayed read-only. The problem there is that all I get from the portal is the file itself or rather some overlay file system thing that makes just that one file available to me. LibreOffice, with its history of being cross-platform, file locking works differently on all different platforms. So it has come up with its own invention of how to do file locking by placing some small file with a special file name next to the original file. And that contains information about who locked that file. So there's even some mode in Calc where you can have multiple users interacting on a single Calc spreadsheet and then there's multiple slots in that file designating who is using it. So that's a quite elaborate format there. And that's of course something that is simple portal that works great for other apps where that falls short a bit for LibreOffice. Where you can't, you just get access to that one file but you can't put a file, put any other file into that directory that the portal gives you so there's no way we can place our lock file there or see the lock file from the outside world. So we figure out we can't put a lock file there so it must be a read-only document so we display it read-only. The API for those portals like this file chooser portal or a print dialog portal, that's all not set in stone yet that still work in progress in a way. So that would have been the first approach how to do that would have been a bit easier for LibreOffice but we'll certainly find ways around all that plus this is all bonus. So the good thing about XCG App being this bundling or packaging so that you can easily distribute it can be seen independent from the second part from the sandboxing. So you can benefit from all the things of the first part without actually needing to modify your apps so that they live in this jail well because that does mean you need to modify in many cases needs to slightly modify your apps. So for example with this file dialog that you need to talk to that special portal file dialog so you need to do some changes in the code there but for the first part that's generally not needed. So the idea is to roll that out in faces and be happy with the first face and then see to get all the little knobs fixed, little knobs adjusted to get this sandbox experience to something that pleases the user. And yeah, that's it if there's any questions there is. Yes, yes and this one was for example allowing no access at all. So you can configure that at the time you build your application and bundle it up for XCG App you specify that time what the defaults are that you want but then of course they can also be overridden at runtime when you start that up. And of course the idea is not that the end user will type in that XCG App and mistype and get a confusing error message as I did but that that will get integrated into GNOME software for example that you just can download it from some well-known repositories of XCG App applications and just run it with a click as you normally do. Scarfs, there was one going up there the man is sleeping and there was one there. There, any more scarfs, any more questions? There's one, yeah of course. So that's again something that you want to weigh the benefits and the problems of it. So what XCG App does offer is that you do have that file system for the app where only the app is mounted but you also have some space in there that is persistent for the LibreOffice configurations. For example when I restart that now that I have opened that one document once it will remember that I opened it and that switched which file dialog to use and all that stuff so all our LibreOffice configuration data does get persisted for the benefit of the user because that's what you typically want. But of course that can mean that you can persist some kind of problem inside the jail. Of course if you are paranoid enough you can always approach that and restart. I think there's even switches to make that easy with XCG App. So if you want to be very, very sure that there can't be any problem with the multiple documents you open or once you open one document and that does look suspicious you can flush out the cache with the downside that all your tweaks to the LibreOffice UI configuration stuff will be gone but you can control that and you can have multiple instances of an XCG App that behave differently in that way. So you could have that one just for these very obscure documents from your employer that you're not sure that you don't want to look at them in the wild. Thank you. Okay. Great, thank you.