8 ms·

Flatpak will be the recommended way to get / install LibreOffice on RHEL and Fedora. In https://lists.fedoraproject.org/archives/list/devel@lists.fedoraprojec

Flatpak will be the recommended way to get / install LibreOffice on RHEL and Fedora. In https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/46ZZ6GZ2W3G4OJYX3BIWTAW75H37TVW6/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... it states: "the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term." Install instructions are already written: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/administering_the_system_using_the_gnome_desktop_environment/assembly_installing-applications-using-flatpak_administering-the-system-using-the-gnome-desktop-environment https://access.redhat.com/documentation/en-us/red_hat_enterp... I would not be surprised if more desktop applications also go to Flatpak on future versions of RHEL. It lets them focus on more enterprise-y features and improve overall security.

criddell 3y ago
I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. If you want to give that application access to everything your user has access to, that’s fine, but it shouldn’t be the default.
- redprince 3y ago
  > If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
  - deleted 3y ago
    [deleted]
  - rajamaka 3y ago
    I always find this take so weird. Do you audit every single line of code from OSS you use?
    - redprince 3y ago
      > Do you audit every single line of code from OSS you use? I audit some of it sometimes. I trust that other do the same. Many hands make light work.
      - pjmlp 3y ago
        Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.
        htag 3y ago
        I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.
        pjmlp 3y ago
        Pentesting is also part of it.
    - matheusmoreira 3y ago
      I don't read every line of code but yeah. I think I spend more time reading code for curiosity's sake than actually using many programs. I absolutely read build system scripts, I won't run make until I know what's gonna happen. I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
- bonzini 3y ago
  > I think this is a small step in the right direction Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates. It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.
- hulitu 3y ago
  > If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. Why would LibreOffice need access to microfone or location ? Asking for a friend.
  - jolux 3y ago
    It shouldn’t, that’s the point.
  - bombcar 3y ago
    PowerPoint let’s you record audio and video for slide presentations- I could see libreoffice having something similar.
- hakfoo 3y ago
  That tends to wave away the responsibilities of the distributor. The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) If you just hand everything off to external self-contained images, you lose a lot of that. I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps. Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.
  - bonzini 3y ago
    > a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue. > be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) That's true, this is potentially something that is lost for interested people.
    - hakfoo 3y ago
      The point was less about the permissions themselves, and more that you're replacing a centralized "everything you want is in one ISO" model to having to retrieve a bunch of packages from third parties after the end of "the main install".
- blablabla123 3y ago
  It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-contained tarball.
  - Gigachad 3y ago
    Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.
- WhyNotHugo 3y ago
  > If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies. OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.
- JohnFen 3y ago
  > Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.
ezst 3y ago
I've been wanting to use LO's flatpacks on my fedora for a while, but I recently gave up and resorted to using the distros' RPMs even though they often lack behind. Global menu, Hi-DPI and kf5 VCL theming just don't work from the official flatpak on my latest KDE+wayland. It seems that several issues are compounded across several stacks (flatpak, dbus, wayland, …) and I don't think there's actually any workaround that works for me. I really hope they get to the bottom of that before dropping the distro's RPMs.
- oneshtein 3y ago
  RPM's are integrated into the OS by a maintainer, Flatpacks are isolated from the OS because of lack of a maintainer. It's not possible to have a cake and eat it too.
kaba0 3y ago
I am not particularly happy with Flatpak - I still think it mixes up two things (packaging, sandbox), and is not particularly good at the former. Nix actually solves the former issue, and does so splendidly. I would much rather see better sandboxes for linux.
- pmoriarty 3y ago
  Agreed, though I'd much rather see this done with Guix.
- aseipp 3y ago
  Well, Nix mostly solves that issue so well due to a continuous massive offering of blood and sweat though, let's not kid ourselves. It's a significant amount of work to package arbitrary software because arbitrary software does weird and bizarre things. But IMO the fundamental principles underlying the design are sound and granular compared to most of the alternatives, though, that's for sure.
  - whateveracct 3y ago
    Luckily (at least for me) Nix makes building and packaging arbitrary software fun. There's something to hacking derivations together, reading documentation, seeing it build and work. At this point, there isn't a C project I can't package in fewer than a handful of sittings. Even when patches are involved!
- jahewson 3y ago
  Nix is great conceptually but after 20 years of boiling the ocean, I would call the experience difficult and erratic, not “splendid”.
  - lostmsu 3y ago
    Dang, I was about to turn my considering trying Nix into practice.
- jzb 3y ago
  I really don’t see how this comment is relevant to the conversation at hand. None of this is about sandboxing libreoffice. It’s simply about a delivery method of getting a libreoffice on a system. Nix is absolutely 1000% not a mainstream solution that’s better than Flatpak for this. If your hobby is tinkering with Nix and marveling at its supposed technical superiority, more power to you. It is absolutely not relevant to this conversation.
oneshtein 3y ago
It's easier to run LibreOffice using Wine than Flatpak.
- Gigachad 3y ago
  How exactly? You just click install in the Gnome software app, and then click the LO icon in your apps list.
  - lost_tourist 3y ago
    Yeah, there's not way it's easier than using rpm/snap/flatpak
b112 3y ago
It lets them focus on more enterprise-y features and improve overall security. Such a minor amount of work saved, if any, and it's all for cost savings, with a reduced user experience. Yup. Redhat as IBM. Modern IBM has fallen so far, and could never, ever create or originate something like redhat. So buy it, they did, and now legions of managers preen, and describe how to "improve" redhat, each cutting, shaving cost, impressed with themselves. And don't believe the "hands off" junk, they still have purse string control.
- toyg 3y ago
  As much as I might dislike IBM, Canonical is doing the same thing. Many established distros are pushing containers for very practical reasons - they shift significant amounts of packaging work from distros to developers. It's annoying but it makes sense.
  - JohnFen 3y ago
    But the packaging work is most of the value that distros give. If they aren't doing that, why do we need distros at all?
    - toyg 3y ago
      > If they aren't doing that, why do we need distros at all? - To set up system daemons in a sane way. You're not going to containerize systemd. - To set up and maintain desktop primitives. You're not going to containerize Wayland or audio systems. - To integrate all these containers in a decent manner. Flatpak and its ilk have limitations that will have to be smoothed over by distros. Will that mean a consolidation, since differences over packaging become less relevant? Maybe. I'm pretty sure we will still have significant differences between The Way RedHat Likes To Do Things, The Way Debian Likes To Do Things, The Way Canonical Likes To Do Things etc etc

criddell 3y ago

I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. If you want to give that application access to everything your user has access to, that’s fine, but it shouldn’t be the default.

redprince 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged. Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
- deleted 3y ago
  [deleted]
- rajamaka 3y ago
  I always find this take so weird. Do you audit every single line of code from OSS you use?
  - redprince 3y ago
    > Do you audit every single line of code from OSS you use? I audit some of it sometimes. I trust that other do the same. Many hands make light work.
    - pjmlp 3y ago
      Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.
      - htag 3y ago
        I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.
        pjmlp 3y ago
        Pentesting is also part of it.
  - matheusmoreira 3y ago
    I don't read every line of code but yeah. I think I spend more time reading code for curiosity's sake than actually using many programs. I absolutely read build system scripts, I won't run make until I know what's gonna happen. I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
bonzini 3y ago
> I think this is a small step in the right direction Yeah, I am obviously biased because I am a Red Hat employee but the truth is the Flatpak model makes a lot of sense for large desktop applications (LibreOffice, OBS, etc.) that anyway do Windows releases and therefore have to track vulnerabilities in their dependencies and release updates. It may take a while to get used to it, but Red Hat has done a lot of infrastructure work to make this sandboxing possible (in RPM ostree, Flatpak, GTK+/GLib, PipeWire and many more places) and it's not a bad thing if they decide that the work is mature enough for them to reap the benefits.
hulitu 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. Why would LibreOffice need access to microfone or location ? Asking for a friend.
- jolux 3y ago
  It shouldn’t, that’s the point.
- bombcar 3y ago
  PowerPoint let’s you record audio and video for slide presentations- I could see libreoffice having something similar.
hakfoo 3y ago
That tends to wave away the responsibilities of the distributor. The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) If you just hand everything off to external self-contained images, you lose a lot of that. I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps. Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.
- bonzini 3y ago
  > a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you. No, it looks a lot like Android or iOS, where the OS vouches for what the app can and cannot do instead of the distributor and there are no privileged scripts running at installation time. You can try it already with Fedora Silverblue. > be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.) That's true, this is potentially something that is lost for interested people.
  - hakfoo 3y ago
    The point was less about the permissions themselves, and more that you're replacing a centralized "everything you want is in one ISO" model to having to retrieve a bunch of packages from third parties after the end of "the main install".
blablabla123 3y ago
It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-contained tarball.
- Gigachad 3y ago
  Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.
WhyNotHugo 3y ago
> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. But Flatpak doesn't ask the user to confirm any permissions, it silently grants any permissions that the application manifest might specifies. OTOH, you don't need to change the packaging system to add sandboxing. It's perfectly feasible to sandbox with firejail or even just plain bubblewrap.
JohnFen 3y ago
> Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. I think I understand this stance, but really, I would consider this to be a terrible outcome. If that's the direction things are going, I really need to stop procrastinating my move away from Linux entirely.

ezst 3y ago

I've been wanting to use LO's flatpacks on my fedora for a while, but I recently gave up and resorted to using the distros' RPMs even though they often lack behind. Global menu, Hi-DPI and kf5 VCL theming just don't work from the official flatpak on my latest KDE+wayland. It seems that several issues are compounded across several stacks (flatpak, dbus, wayland, …) and I don't think there's actually any workaround that works for me. I really hope they get to the bottom of that before dropping the distro's RPMs.

oneshtein 3y ago
RPM's are integrated into the OS by a maintainer, Flatpacks are isolated from the OS because of lack of a maintainer. It's not possible to have a cake and eat it too.

kaba0 3y ago

I am not particularly happy with Flatpak - I still think it mixes up two things (packaging, sandbox), and is not particularly good at the former. Nix actually solves the former issue, and does so splendidly. I would much rather see better sandboxes for linux.

pmoriarty 3y ago
Agreed, though I'd much rather see this done with Guix.
aseipp 3y ago
Well, Nix mostly solves that issue so well due to a continuous massive offering of blood and sweat though, let's not kid ourselves. It's a significant amount of work to package arbitrary software because arbitrary software does weird and bizarre things. But IMO the fundamental principles underlying the design are sound and granular compared to most of the alternatives, though, that's for sure.
- whateveracct 3y ago
  Luckily (at least for me) Nix makes building and packaging arbitrary software fun. There's something to hacking derivations together, reading documentation, seeing it build and work. At this point, there isn't a C project I can't package in fewer than a handful of sittings. Even when patches are involved!
jahewson 3y ago
Nix is great conceptually but after 20 years of boiling the ocean, I would call the experience difficult and erratic, not “splendid”.
- lostmsu 3y ago
  Dang, I was about to turn my considering trying Nix into practice.
jzb 3y ago
I really don’t see how this comment is relevant to the conversation at hand. None of this is about sandboxing libreoffice. It’s simply about a delivery method of getting a libreoffice on a system. Nix is absolutely 1000% not a mainstream solution that’s better than Flatpak for this. If your hobby is tinkering with Nix and marveling at its supposed technical superiority, more power to you. It is absolutely not relevant to this conversation.

oneshtein 3y ago

It's easier to run LibreOffice using Wine than Flatpak.

Gigachad 3y ago
How exactly? You just click install in the Gnome software app, and then click the LO icon in your apps list.
- lost_tourist 3y ago
  Yeah, there's not way it's easier than using rpm/snap/flatpak

b112 3y ago

It lets them focus on more enterprise-y features and improve overall security. Such a minor amount of work saved, if any, and it's all for cost savings, with a reduced user experience. Yup. Redhat as IBM. Modern IBM has fallen so far, and could never, ever create or originate something like redhat. So buy it, they did, and now legions of managers preen, and describe how to "improve" redhat, each cutting, shaving cost, impressed with themselves. And don't believe the "hands off" junk, they still have purse string control.

toyg 3y ago
As much as I might dislike IBM, Canonical is doing the same thing. Many established distros are pushing containers for very practical reasons - they shift significant amounts of packaging work from distros to developers. It's annoying but it makes sense.
- JohnFen 3y ago
  But the packaging work is most of the value that distros give. If they aren't doing that, why do we need distros at all?
  - toyg 3y ago
    > If they aren't doing that, why do we need distros at all? - To set up system daemons in a sane way. You're not going to containerize systemd. - To set up and maintain desktop primitives. You're not going to containerize Wayland or audio systems. - To integrate all these containers in a decent manner. Flatpak and its ilk have limitations that will have to be smoothed over by distros. Will that mean a consolidation, since differences over packaging become less relevant? Maybe. I'm pretty sure we will still have significant differences between The Way RedHat Likes To Do Things, The Way Debian Likes To Do Things, The Way Canonical Likes To Do Things etc etc